System for coordinating distributed devices with cryptographic task verification

Abstract

A system for coordinating distributed nodes in a network, utilizing mechanisms to ensure task execution, accountability, and resource monitoring. The system employs trusted execution environments (TEEs) or cryptographic techniques, such as zero-knowledge proofs (ZKPs), to produce tamper-proof cryptographic proofs of task completion and physical output. Blockchain technology integrates with these mechanisms to provide decentralized validation. Resource usage, including metrics like energy consumption and bandwidth, is tracked and cryptographically validated, enabling accurate monitoring and fair resource allocation. The system supports scalable and secure operations across diverse applications, including loT networks (e.g., distributed lighting systems) and decentralized infrastructure for task and resource sharing, bridging the gap between digital and physical-world verification while addressing inefficiencies and scalability challenges in prior art.

Description

Attorney Docket No. 11855-002W01System for Coordinating Distributed Devices with Cryptographic Task Verification

[0001] This application claims priority to, and the benefit of, U. S. Provisional Patent Application No. 63 / 725,796, filed November 27, 2024, entitled “SECURE CYPTO-HARDWARE AND SYNCHRONIZATION ’ which is incorporated by reference herein its entirety.Field of the Invention

[0002] The application relates to distributed and decentralized systems for verifying task execution and resource usage using cryptographic and hardware-based mechanisms, optionally coordinated through decentralized ledgers.Background

[0003] In modem distributed networks, coordinating the operation of nodes presents significant challenges, particularly in ensuring task execution, accountability, scalability, economic coordination, and resource utilization. Existing solutions often rely on centralized control mechanisms, lack generality, or are tailored to specific applications, creating barriers to decentralized operation and fair resource sharing. These issues are especially pronounced in networks comprising nodes with different owners, where trust and equitable compensation are critical.

[0004] There is a benefit to improving distributed networks.Summary

[0005] An exemplary’ general-purpose system and method are disclosed that can be employed for verifying task execution across physical and digital domains, enabling trustworthy operation of distributed, centralized, or hybrid netw orks of devices. The exemplary’ system employs a unified architecture in which tasks are executed within secure, tamper-resistant computing environments, measurements of resulting outputs are obtained through authenticated sensing pathways, and cryptographic proofs of correctness are generated for external verification, audit, or compensation.

[0006] In some embodiments, a node is configured with a secure module that is configured to execute an assigned task and a proof engine that evaluates sensor data or internal execution traces against verification parameters. The proof engine is configured to generate a cryptographic proof (e.g., a digital signature, attestation record, or zero-knowledge proof) to indicate whether the task w as performed within expected bounds. The resultingAttorney Docket No. 11855-002W01task verification proof may then be transmitted to a coordinator, peer nodes, or a ledger, which in different embodiments may comprise a blockchain, replicated append-only log. authenticated data structure, distributed hash table, conflict-free replicated data type, secure local log with periodic commitments, or other cryptographically authenticated record-keeping mechanism.

[0007] In various embodiments, the system verifies tasks involving physical output, including light emission, motion, energy usage, vibrations, acoustic patterns, fluid flow, electromagnetic signals, or other measurable phenomena. The secure module may incorporate co-located sensors, internal optical or electromagnetic pathways, multi-sensor fusion, AI-based observers that derive semantic features from raw sensor data, and physical antispoofing architectures to ensure that sensor data reflects genuine actuator output and cannot be externally injected, replayed, or falsified without detection.

[0008] In additional embodiments, the system can support secure task execution without explicit physical output measurement, wherein the secure module generates a tamperresistant execution attestation that reflects actuator commands produced by an authenticated, measured software image. In such embodiments, assurance is derived from isolation of actuator-control logic, code measurement and attestation, and cryptographically signed execution logs, providing strong evidence that the assigned task was executed as commanded even when physical output verification is omitted or unavailable.

[0009] The system further supports timing-dependent tasks, including phase alignment, temporal coordination, and latency-constrained operations. Nodes may derive timing from global references, relative phase markers, decentralized timing beacons, local oscillators, environmental periodic signals, network-based timing exchanges, neighbor-based timing pulses, or combinations thereof. Timing information may be incorporated into task windows, verification windows, sensor data, or task verification proofs, to provide a verification operation of whether a node’s behavior satisfied assigned timing tolerances across a range of timing “tightness,’' from sub-millisecond global synchronization to coarse, event-ordered execution.

[0010] To ensure scalability in high-rate sensing deployments, the system may generate authenticated sensor samples at high frequency within the secure module while transmitting only window-level commitments or summaries under normal operation.Verifiers may perform selective audits by requesting disclosure of specific samples, integrity metadata, or Merkle paths, recomputing commitments and statistics to detect tampering orAttorney Docket No. 11855-002W01misreporting. This selective-audit mechanism enables tamper-evident verification of dense sensor data streams without requiring continuous transmission of all raw measurements.

[0011] In decentralized or coordinator-free embodiments, nodes assign tasks and verify task verification proofs peer-to-peer, maintain local, authenticated logs, exchange signed summaries or reputation metrics, and apply quorum or threshold logic to determine task correctness without relying on a centralized authority or a shared global ledger. Nodes may also use capability keys or other cryptographic tokens derived from node identity to control participation, enforce economic incentives, or govern access to timing and verification services.

[0012] Across these embodiments, the exemplary system is implemented as a modular, tamper-resistant, and cryptographically verifiable framework for ensuring that assigned tasks (whether physical, logical, or hybrid) are executed as specified. The architecture is adaptable to diverse actuators, sensors, timing regimes, network structures, AI-based observers, and verification requirements, enabling secure coordination and scalable verification of distributed devices in a wide range of applications.

[0013] The present disclosure provides an improvement to computing technology. Despite advances in distributed systems, there is no general-purpose, tamper-resistant mechanism for verifying that a remotely assigned physical-world task was actually executed as specified. Current approaches cannot reliably (i) confirm that a node produced the required physical output (e.g.. light intensity, motion, energy), (ii) validate sensor data in adversarial or untrusted environments, (iii) prevent falsified, simulated, or replayed results, or (iv) coordinate verification among independently owned or loosely connected nodes.Furthermore, there is no unified framework that integrates (i) secure execution (e.g., TEEs or sealed cryptographic modules), (ii) physical sensing of outputs, (iii) cryptographic comparison of expected vs. measured values, and (iv) optional decentralized record-keeping for audit or compensation, in a way that generalizes across applications such as lighting systems, drones, robotics, audio-reactive installations, or other distributed physical infrastructures.

[0014] Notably, prior and current systems (i) lack robust validation, (ii) are centralized and reliant, and (iii) have application-specific limitations. With respect to robust validation, current systems often lack secure mechanisms for task verification, particularly for tasks with physical output. Examples include lighting controllers that assume brightness without sensing, robotic actuators that report internal state without external validation, and loT devices that rely solely on software-reported status. Such systems cannot detect falsified.Attorney Docket No. 11855-002W01simulated, or replayed sensor data and are vulnerable to spoofing, tampering, or silent failure. With respect to being centrally reliant, many systems depend on a centralized validator or cloud service to confirm correct execution. This introduces single points of failure, creates trust bottlenecks, increases latency, and prevents independent operators from verifying correctness without relying on third-party infrastructure. And, with respect to applicationspecific limitations, most solutions are optimized for narrow applications such as smart lighting, drones, or metering and cannot generalize across domains. They lack modular verification components and cannot accommodate heterogeneous actuators, sensors, or timing modalities.

[0015] In some aspects, the techniques described herein relate to a system for verifying task execution in a distributed or centralized network, including: a coordinator configured to assign a task having parameters and expected bounds to one or more nodes; at least one node including (i) a secure module configured to execute the task and (ii) a resource monitor that measures a resulting output, wherein the secure module includes a proof engine configured to compare the measured output with the expected bounds and generate a cryptographic proof of correctness; and a verification mechanism within the coordinator that receives and validates the cryptographic proof (e g., wherein the proof may optionally be recorded on a decentralized ledger, thereby providing tamper-resistant validation of task completion).

[0016] In some aspects, the techniques described herein relate to a system, wherein the secure module includes a Trusted Execution Environment (TEE) or secure enclave that isolates task execution and proof generation from external tampering.

[0017] In some aspects, the techniques described herein relate to a system, wherein the cryptographic proof includes a zero-knowledge proof that validates task correctness without revealing task data.

[0018] In some aspects, the techniques described herein relate to a system, wherein the resource monitor includes one or more physical sensors that measure light intensity, power consumption, motion, or environmental conditions.

[0019] In some aspects, the techniques described herein relate to a system, wherein the ledger includes a blockchain that immutably records task identifiers, proofs, or compensation transactions.

[0020] In some aspects, the techniques described herein relate to a system, wherein the coordinator automatically releases payment or credit to the node upon successful verification of the proof.Attorney Docket No. 11855-002W01

[0021] In some aspects, the techniques described herein relate to a system, wherein the node can operate with other nodes in parallel groups, each producing independent proofs of task completion that are verified by the coordinator.

[0022] In some aspects, the techniques described herein relate to a system, wherein the secure module and resource monitor are co-located within a single node.

[0023] In some aspects, the techniques described herein relate to a system, wherein the resource monitor includes a trained Al model executing within a secure module, the trained Al model configured to generate semantic features from sensor measurements for comparison against verification parameters.

[0024] In some aspects, the techniques described herein relate to a system, wherein the verification parameters specify a sequence of transitions and associated timing tolerances, and the proof engine generates a cryptographic proof that the sequence of transitions conform to the specified sequence.

[0025] In some aspects, the techniques described herein relate to a system, wherein a synchronization mechanism supports a global time mode in which a node verifies task execution using an absolute or quasi-absolute timing reference, the task verification proof further including a timing proof indicating that the node's local clock was within a permitted skew relative to the timing reference.

[0026] In some aspects, the techniques described herein relate to a system, wherein the synchronization mechanism supports a relative phase alignment mode in which nodes derive a shared epoch or phase marker without reference to absolute time, and the proof engine verifies that the physical output is aligned with the assigned phase or beat index within a phase-error tolerance.

[0027] In some aspects, the techniques described herein relate to a system, wherein the synchronization mechanism supports a coarse or asynchronous timing mode in which verification is performed using local timestamps, counters, or externally observable triggers without requiring a globally shared clock.

[0028] In some aspects, the techniques described herein relate to a system, wherein the task verification proof further includes timing metadata selected from the group consisting of: local timestamps, event counters, drift estimates, phase offsets, beat indices, or timing-quality metrics.

[0029] In some aspects, the techniques described herein relate to a system, further including an execution attestation mode in which the secure module generates aAttorney Docket No. 11855-002W01cryptographic execution log that records actuator commands and internal status information without requiring measurement of a physical output by the resource monitor.

[0030] In some aspects, the techniques described herein relate to a system, wherein the secure module generates authenticated high-frequency sensor samples and produces a window -level commitment summarizing the samples, the commitment being verifiable against selectively disclosed samples during an audit.

[0031] In some aspects, the techniques described herein relate to a system, wherein a verifier performs selective audits by requesting specific sample indices or ranges and validating the disclosed samples against a Merkle root or chained-hash commitment included in the task verification proof.

[0032] In some aspects, the techniques described herein relate to a system, wherein the secure module authenticates sensor data from an external sensor using a digital signature, message authentication code, secure timestamp, or challenge-response protocol.

[0033] In some aspects, the techniques described herein relate to a system, wherein the secure module performs multi-sensor fusion by combining measurements from two or more sensors selected from the group consisting of: optical sensors, IMUs, electrical sensors, magnetic encoders, microphones, or environmental sensors. In some embodiments, the secure module can authenticate sensor data from an external sensor using one or more of: a digital signature, a message-authentication code (MAC), an authenticated-encryption channel, a session key derived from an authenticated key-exchange protocol, a nonce or monotonic counter for freshness, a secure timestamp, a hash-chain or Merkle-commitment proof, a hardware-bound attestation key, a physically unclonable function (PUF)-based response, a challenge-response protocol, or cross-sensor integrity checks that validate consistency across multiple sensing modalities. These mechanisms ensure that sensor data originates from a genuine external sensor, has not been tampered with, and is bound to the correct task and verification window.

[0034] In some aspects, the techniques described herein relate to a system, wherein the proof engine generates the task verification proof based on fused sensor data derived from both internal and external sensors operating at different trust levels.

[0035] In some aspects, the techniques described herein relate to a system, wherein the node identity includes a hierarchical key structure derived from a root secret or seed phrase, the hierarchy including one or more subordinate keys for proof signing, capability issuance, or secure communication.Attorney Docket No. 11855-002W01

[0036] In some aspects, the techniques described herein relate to a system, wherein the node identity is compatible with Ethereum-style elliptic-curve key systems and the public component of the identity key is stored on a ledger to enable decentralized authentication.

[0037] In some aspects, the techniques described herein relate to a method for verifying task execution in a distributed or centralized network, including: assigning, by a coordinator, task parameters and expected bounds to a node; executing, by a secure module within the node, the assigned task; eliciting and capturing, by a resource monitor, a physical output of the task; comparing, by a proof engine within the secure module, the physical output with the expected bounds; generating, by the proof engine, a cry ptographic proof of correctness (e.g., signature or zero-knowledge proof); transmitting the proof to the coordinator; optionally recording a digest of the proof on a decentralized ledger; and verifying, by the coordinator, the proof and recording the verified result.

[0038] In some aspects, the techniques described herein relate to a method, further including: computing, by the secure module, a deviation value between measured and expected results and signing a tuple of task identifier, measured value, target value, and pass / fail status.

[0039] In some aspects, the techniques described herein relate to a method, wherein verification includes batch-processing a plurality of proofs and committing their digests to the ledger in a single transaction.

[0040] In some aspects, the techniques described herein relate to a method, wherein the network includes mobile nodes, each node including an actuator and sensor that verify phase or timing alignment within a predefined tolerance.

[0041] In some aspects, the techniques described herein relate to a method, wherein proof generation and verification employ asymmetric cryptography using Ed25519 signatures or equivalent schemes.

[0042] In some aspects, the techniques described herein relate to a method, wherein task verification is performed without reliance on a centralized authority.

[0043] In some aspects, the techniques described herein relate to a method, wherein compensation is automatically distributed to nodes whose proofs are verified as valid.

[0044] In some aspects, the techniques described herein relate to a method, wherein generating the cryptographic proof further includes executing an attested Al inference model within the secure module to produce feature-level or classification-level measurements of the physical output.Attorney Docket No. 11855-002W01

[0045] In some aspects, the techniques described herein relate to a method, wherein the physical output includes a red, yellow, or green traffic-signal illumination pattern and the secure module verifies that the measured illumination matches the commanded state within a predetermined tolerance.

[0046] In some aspects, the techniques described herein relate to a method, wherein the task window and verification window are defined with sub-millisecond precision relative to a global timing reference, and verifying the proof includes checking that the node's reported timing error is below a predetermined threshold. In other embodiments, the task window and verification window are defined with high-precision timing relative to a global timing reference, including but not limited to millisecond- or sub-millisecond-level precision, and verifying the proof includes checking that the node’s reported timing error is below a predetermined threshold.

[0047] In some aspects, the techniques described herein relate to a method, wherein the task window and verification window are defined relative to a shared epoch derived from timing beacons exchanged among nodes, and verifying the proof includes evaluating phase alignment or beat index consistency.

[0048] In some aspects, the techniques described herein relate to a method, wherein the task window and verification window are defined using coarse timing constraints expressed as minimum or maximum delays, event ordering, or deadlines based on local time, and verifying the proof includes determining whether the reported execution occurred within the specified constraints.

[0049] In some aspects, the techniques described herein relate to a method, wherein generating the cry ptographic proof further includes including one or more timing-quality metrics indicating oscillator stability, drift correction applied, or timing-source confidence.

[0050] In some aspects, the techniques described herein relate to a method, further including: generating, by the secure module, an execution attestation record that includes a hash of actuator commands, timestamps, and a status code, and signing the record with a key bound to an attested software image, wherein verification of the record provides assurance that the assigned task was executed as commanded, even in the absence of explicit physical output measurement.

[0051] In some aspects, the techniques described herein relate to a method, further including: grouping sensor samples into window s, generating a cryptographic commitment for each window, and transmitting only a window-level proof unless a verifier issues a challenge requiring disclosure of individual samples.Attorney Docket No. 11855-002W01

[0052] In some aspects, the techniques described herein relate to a method, wherein failure of a node to produce selectively requested samples or integrity’ metadata results in reduction of credit, revocation of capability keys, or exclusion from subsequent tasks.

[0053] In some aspects, the techniques described herein relate to a method, further including: deriving, by the secure module, a capability key from a node's root identity key based on an epoch identifier, credit state, or task policy, and authorizing task execution only upon verification of the capability key.

[0054] In some aspects, the techniques described herein relate to a method, wherein the secure module derives subordinate keys from a root identity’ key using a hierarchical deterministic derivation function, and uses the subordinate keys for signing task verification proofs, encrypting communication, or authorizing participation in distributed timing or audit protocols.

[0055] In some aspects, the techniques described herein relate to a method, further including: authenticating sensor data from a semi-trusted external sensor using cryptographic integrity metadata and integrating the authenticated data with internal sensor measurements during the verification process.Brief Description of the Drawings

[0056] Figs. 1 A, IB, and 1C each show an example system configured with a secure module for task verification operation of a node device in a distributed system in accordance with an illustrative embodiment.

[0057] Figs. 2A and 2B show a system of secure modules of Figs. 1A and 1B, respectively, for task verification operation in accordance with an illustrative embodiment.

[0058] Figs. 3A - 3F each show an example operation of the system of Figs. 1A - 1C in accordance with an illustrative embodiment.

[0059] Figs. 4A - 4B show examples of hardware trust boundaries and multi-sensor fusion configuration, in accordance with an illustrative embodiment.

[0060] Fig. 5 shows physical anti-spoofing structures that may be employed in the secure module to ensure sensor integrity, in accordance with an illustrative embodiment.

[0061] Figs. 6A - 6F each show an example operation for the system of any one of Figs. 1 A - 1C, in accordance with an illustrative embodiment.

[0062] Figs. 7A - 7C each show example verification operations for the system and method described herein, in accordance with an illustrative embodiment.Attorney Docket No. 11855-002W01

[0063] Figs. 8A - 8C show example observer configurations, including for multiobserver and Al-based observer, in accordance with an illustrative embodiment.

[0064] Fig. 9A shows an exemplary system and methods in the context of a timing architecture, in accordance with an illustrative embodiment.

[0065] Figs. 9B - 9F show examples of ledger configurations that may be used with the above-discussed system and method, in accordance with an illustrative embodiment.

[0066] Figs. 10A and IB each show an example operation of the coordinator-free, ledger-free embodiment, in accordance with an illustrative embodiment.

[0067] Figs. 11 A and 1 IB each show examples of sensory modalities that may be used with the verification controller of the system and methods, in accordance with an illustrative embodiment.

[0068] Figs. 12A - 12D show a value exchange mechanism that may be implemented using the system and method described herein. A value exchange mechanism is a component or logic that enables the distribution of rewards, payments, or credits for verified task execution.

[0069] Various objects, aspects, features, and advantages of the disclosure will become more apparent and better understood by referring to the detailed description taken in conjunction with the accompanying drawings, in which like reference characters identify corresponding elements throughout. In the drawings, like reference numbers generally indicate identical, functionally similar, and / or structurally similar elements.Detailed Description

[0070] Each and every feature described herein, and each and even’ combination of two or more of such features, is included within the scope of the present invention provided that the features included in such a combination are not mutually inconsistent.

[0071] Some references, which may include various patents, patent applications, and publications, are cited in a reference list and discussed in the disclosure provided herein. The citation and / or discussion of such references is provided merely to clarify' the description of the present disclosure and is not an admission that any such reference is "prior art” to any aspects of the present disclosure described herein. In terms of notation, “[n]” corresponds to the nthreference in the list. All references cited and discussed in this specification are incorporated herein by reference in their entirety and to the same extent as if each reference was individually incorporated by reference.

[0072] Example SystemAttorney Docket No. 11855-002W01

[0073] Figs. 1A, 1B, and 1C each show an example system 100 (shown as 100a, 100b, 100c, respectively) configured with a secure module for task verification operation of a node device in a distributed system in accordance with an illustrative embodiment. Figs. 2A and 2B show a system of secure modules of Figs. 1A and 1B, respectively, for task verification operation in accordance with an illustrative embodiment.

[0074] In the example shown in Figs. 1A, 1B, and 1C, the system 100a includes a node 102, a secure module 104, a processing unit 106, an actuator 108, an execution log 110, a verification controller 111 (e.g., a proof engine 105), and a sensor 112. The node 102 is a distributed device capable of receiving tasks 114 (shown as “Task assignments” 114), executing operations, producing physical outputs 116, measuring the outputs 118 (shown as “sensor 112 data” 118), and generating proofs 120 (shown as “Verification results” 120 in Fig. 1A and “Task verification proof’ 121 in Fig. IB). Fig. 1B shows the node 102 additionally interacting with a ledger 122.

[0075] In Figs. 1A, 1B, and 1C, the secure module 104 is a protected environment (TEE, enclave, hardware-isolated logic, or equivalent) that ensures tamper-resistant processing of measurements and / or cryptographic proof generation. The secure module 104 preferably employs a proof engine 105 to perform the operations necessary ■ to produce a tamper-resistant task verification proof 121. Task verification proof 121 is a cryptographic proof that a node 102 executed a task within expected bounds. The processing unit 106 is a subsystem that receives a task assignment 114 comprising task parameters, the task assignment being used to drive the actuator 108 to execute a task. Task assignment 114 is a structured parameters or commands delivered to a node 102, defining the expected output and verification bounds. The actuator 108 is a component that produces the commanded physical output 116 associated with the task. The execution log 110 is a structured record generated within the secure module 104 that captures actuator-command sequences, internal status information, timing metadata, software-image identifiers, or other signals reflecting task execution. The execution log 110 is authenticated and evaluated by the proof engine when physical output verification is omitted or unavailable. It provides a tamper-resistant basis for generating an execution-only attestation. The sensor 112 is a component that measures physical-world outputs for use in task verification. Sensor data 118 are measurements captured by the sensor 112 and used by the secure module 104 for comparison against expected bounds, e.g., verification parameters. Verification parameters are expected bounds, tolerances, timing windows, or other criteria used to evaluate the sensor data 118. PhysicalAttorney Docket No. 11855-002W01output 116 is a real-world effect produced by a node's actuator 108. Task proof submission is a transmission of generated proofs from a node 102 to a coordinator 126 or ledger 128.

[0076] Resource monitor 124 is a mechanism that tracks and validates resource usage (energy, bandwidth, duty cycle, mechanical work) for accountability or compensation.Coordinator 126 is a component or node 102 that assigns tasks, receives proofs, validates them, and optionally records them on a ledger or other authenticated log. In coordinator-free embodiments, e.g., as described in relation to Figs. 10 A, the functions are distributed among multiple nodes 102, and no dedicated coordinator 126 is required. Ledger 128 is a decentralized or append-only system that stores proofs, task records, and compensation events. In some embodiments, the ledger is a blockchain; in others, it comprises a replicated log, distributed hash table, authenticated database, or locally maintained append-only log. In ledger-free embodiments, nodes 102 retain local records or exchange signed summaries without any shared ledger, e.g., as described in relation to Figs. 9A - 9F. Local ledger instance 130 is a local or synchronized representation of a distributed ledger used for task assignment, proof submission, or state tracking.

[0077] Node identity / cryptographic identity is a unique identifier and key hierarchy used for secure task assignment, proof signing, and capability control that may be employed by the secure module 104. In some embodiments, the node identity is derived from or compatible with hierarchical key systems, such as those based on Ethereum-style elliptic-curve keys or hierarchical deterministic (HD) derivation schemes. A root identity key may derive subordinate keys for signing proofs, generating capability keys, encrypting task parameters, or authorizing participation in specific operational epochs.

[0078] Example Proof Engine

[0079] A proof engine 105 is a subsystem, preferably located within the secure module (e.g., 104), that performs one or more operations necessary to produce a tamperresistant task verification proof. In various embodiments, the proof engine 105 may: (i) receive sensor data 118, Execution Logs, timing metadata, or multi-sensor fused data; (ii) evaluate these inputs against verification parameters, tolerance bounds, timing conditions, or semantic constraints; (iii) compute deviation metrics, pass / fail determinations, threshold comparisons, semantic-feature matches, timing alignment values, or other evaluative results; (iv) generate a cryptographic proof of correctness using signatures, attestations, messageauthentication codes, chained-hash or Merkle commitments, capability keys, or zeroknowledge proof techniques; (v) incorporate authenticated high-frequency sensor-sample commitments or selective-audit structures; (vi) produce timing proofs reflecting clock drift.Attorney Docket No. 11855-002W01epoch alignment, or phase consistency; (vii) produce execution attestations when physical output 116 verification is omitted, including hashes of actuator-command sequences, internal status codes, or measured software-image identifiers; and (viii) bind all outputs to a node 102 Identity or measured software identity associated with the secure module.

[0080] The proof engine 105 may operate on raw measurements, derived features, semantic AI inference results, fused multi-modal sensor data, or execution-only internal signals. In some embodiments, portions of the proof engine 105 may reside outside the secure module 104 when cryptographic integrity is preserved, provided that all proof-critical steps and signing operations occur within a tamper-resistant boundary.

[0081] Fig. 1A shows the node 102 comprising the secure module 104 with the actuator 108 and sensor 112 to generate a task verification result 120. The results 120 may be employed, e.g., by the processing unit 106, to generate a task verification proof 121. Fig. 1B shows the node 102 comprising the secure module 104 with the sensor 112 to generate task verification proof 121, the secure module 104 operating with the actuator 108, e.g., located in the node 102. Fig. 1B also shows an example task window 132 and verification window 134. The example task window 132 and verification window 134 may be performed in relation to the system of Figs. 1A, 1B, and / or 1C. Fig. 1C shows the node 102 comprising the secure module 104 with the sensor 112.

[0082] Fig. 1C shows an example system 100c in which a node 102 includes a secure module 104, a processing unit 106, an actuator 108. a sensor 112. and an execution log 110. The verification controller 111 (e.g., proof engine 105) evaluates actuator-command records and any available sensor data 118 to generate verification results 120. The node may further interact with a resource monitor 124, a coordinator 126, and a ledger 128 via a local ledger instance 130.

[0083] In some embodiments, the system can verify task execution in a distributed or centralized network, including: a coordinator configured to assign a task having parameters and expected bounds to one or more nodes; at least one node including (i) a secure module configured to execute the task and (ii) a resource monitor that measures a resulting output, wherein the secure module includes a proof engine configured to compare the measured output with the expected bounds and generate a cryptographic proof of correctness: and a verification mechanism within the coordinator that receives and validates the cryptographic proof (e.g., wherein the proof may optionally be recorded on a decentralized ledger, thereby providing tamper-resistant validation of task completion).Attorney Docket No. 11855-002W01

[0084] In some embodiments, the system can operate in a Trusted Execution Environment (TEE) or secure enclave that isolates task execution and proof generation from external tampering.

[0085] In some embodiments, the system can perform a cryptographic proof that validates task correctness without revealing task data.

[0086] In some embodiments, the system employs a resource monitor that includes one or more physical sensors that measure light intensity, power consumption, motion, or environmental conditions.

[0087] In some embodiments, the system includes a ledger that includes a blockchain that immutably records task identifiers, proofs, or compensation transactions.

[0088] In some embodiments, the system includes a coordinator that can automatically release payment or credit to the node upon successful verification of the proof.

[0089] In some embodiments, the system can include a node that can operate with other nodes in parallel groups, each producing independent proofs of task completion that are verified by the coordinator.

[0090] In some embodiments, the system includes a secure module and a resource monitor that are co-located within a single node.

[0091] In some embodiments, the system includes a resource monitor that includes a trained AI model, the trained AI model configured to generate semantic features from sensor measurements for comparison against verification parameters.

[0092] In some embodiments, the system employs verification parameters that specify a sequence of transitions and associated timing tolerances, the system comprising a proof engine that can generate a cryptographic proof that the sequence of transitions conforms to the specified sequence.

[0093] In some embodiments, the system includes a synchronization mechanism that supports a global time mode in which a node verifies task execution using an absolute or quasi-absolute timing reference, the task verification proof further including a timing proof indicating that the node's local clock was within a permitted skew relative to the timing reference.

[0094] In some embodiments, the synchronization mechanism supports a relative phase alignment mode in which nodes derive a shared epoch or phase marker without reference to absolute time, and the proof engine verifies that the physical output is aligned with the assigned phase or beat index within a phase-error tolerance.Attorney Docket No. 11855-002W01

[0095] In some embodiments, the synchronization mechanism supports a coarse or asynchronous timing mode in which verification is performed using local timestamps, counters, or externally observable triggers without requiring a globally shared clock.

[0096] In some embodiments, the system can perform task verification proof using timing metadata selected from the group consisting of: local timestamps, event counters, drift estimates, phase offsets, beat indices, or timing-quality metrics.

[0097] In some embodiments, the system can operate in an execution attestation mode in which the secure module generates a cryptographic execution log that records actuator commands and internal status information without requiring measurement of a physical output by the resource monitor.

[0098] In some embodiments, the system can include a secure module that can generate authenticated high-frequency sensor samples and produce a window-level commitment summarizing the samples, the commitment being verifiable against selectively disclosed samples during an audit.

[0099] In some embodiments, the system includes a verifier configured to perform selective audits by requesting specific sample indices or ranges and validating the disclosed samples against a Merkle root or chained-hash commitment included in the task verification proof.

[0100] In some embodiments, the system includes a secure module that can authenticate sensor data from an external sensor using a digital signature, message authentication code, secure timestamp, or challenge-response protocol.

[0101] In some embodiments, the system includes a secure module that can perform multi-sensor fusion by combining measurements from two or more sensors selected from the group consisting of: optical sensors, IMUs, electrical sensors, magnetic encoders, microphones, or environmental sensors. In some embodiments, the secure module can authenticate sensor data from an external sensor using one or more of: a digital signature, a message-authentication code (MAC), an authenticated-encryption channel, a session key- derived from an authenticated key-exchange protocol, a nonce or monotonic counter for freshness, a secure timestamp, a hash-chain or Merkle-commitment proof, a hardware-bound attestation key, a physically unclonable function (PUF)-based response, a challenge-response protocol, or cross-sensor integrity checks that validate consistency across multiple sensing modalities. These mechanisms ensure that sensor data originates from a genuine external sensor, has not been tampered with, and is bound to the correct task and verification window.Attorney Docket No. 11855-002W01

[0102] In some embodiments, the system includes a proof engine that can generate the task verification proof based on fused sensor data derived from both internal and external sensors operating at different trust levels.

[0103] In some embodiments, the system includes a node having a node identity that includes a hierarchical key structure derived from a root secret or seed phrase, the hierarchy including one or more subordinate keys for proof signing, capability issuance, or secure communication. In some embodiments, the node identity is compatible with Ethereum-style elliptic-curve key systems and the public component of the identity key is stored on a ledger to enable decentralized authentication.

[0104] Figs. 2A and 2B each show multiples of the nodes 102 of Figs. 1A and IB operating 200 (shown as 200a. 200b) in a distributed manner for task verification operation in accordance with an illustrative embodiment. It should be understood that the system of Figs.1C and operate in a similar manner as that described for Figs. 2A and 2B.

[0105] In Fig. 2A, each of the nodes 102 (shown as 102a, 102b,..., 102c) includes a secure module 104 that operates with a processing unit 106 to execute operations, produce physical outputs 116, measure the outputs 118, and generate proofs 120.

[0106] In Fig. 2B, each of the nodes 102 (shown as 102a, 102b,..., 102c) includes a secure module 104, a local ledger instance 130, and a processing unit 106. The secure module 104 and processing 106 can execute operations, produce physical outputs 116, measure the outputs 118, and generate proofs 121 that is provided to the local ledger instance 130. The local ledger instance 130 can perform synchronization and task proof submission operations with the ledger 128.

[0107] Example Method of Operation

[0108] Figs. 3A - 3F each show an example operation of the system of Figs. 1A - 1C in accordance with an illustrative embodiment. Other example operations are described herein, e.g., in relation to Figs. 4 - 11.

[0109] Example Method #1. Fig. 3A shows an example operation 300a of the system of Fig. 1A or 1C. In Fig. 3A, the method 300a includes an external device or system providing a task assignment 114 to a node 102 comprising a processing unit 106, actuator 108, and secure module 104. The secure module 104 includes (i) a sensor 112 to receive measured sensor data 118 from a physical output generated by the actuator 108 and (ii) a proof engine 105 configured to verify and generate a verification result 120 to return to the external system or device.Attorney Docket No. 11855-002W01

[0110] Example Method #2. Fig. 3B shows an example operation 300b of the system of Fig. 1B. In Fig. 3B, the method 300b includes a ledger 128 providing a task through a synchronization operation to a node executing a local ledger instance 130. The local ledger instance 130 generates a task assignment 114 to a processing unit 106 that executes a task via an actuator 108. A sensor 112 of a secure module 104 measures a physical output 116 of the actuator 108 to generate sensor data 118 for a verification controller 111 of the secure module 104 to generate a verification proof 121 to provide back to the local ledger instance 130. The local ledger instance 130 then provides a task proof submission message to the distributed ledger 128.

[0111] Example Proof Engine Pipeline Method #3. Fig. 3C shows an example verification sequence 300c in which the secure module 104 executes an internal proofgeneration pipeline. In Fig. 3C, the proof engine pipeline is shown operating within a secure module 104. Inputs may include sensor data 118, execution logs 110 (shown as optional), internal timing sources (shown as optional), and cryptographic hardware (shown as optional). The verification controller 111 (e.g.. proof engine 105) is configured to verify the event / task to generate a task verification proof 121. An example of a secured proof engine may be implemented, e.g., as described in relation to Fig. 6C.

[0112] Example Tamper-Proof Secure Module Method #4. Fig. 3D shows an example sequence for a secure execution-only attestation, in which the secure module 104 evaluates actuator-command traces and internal status information recorded in the execution log 110 and generates a verification result (e.g., 120) or task verification proof (e.g., 121) without requiring physical-output measurement. In Fig. 3D, the proof engine pipeline 300d is shown operating within a secure module 104. Inputs may include sensor data 118, execution logs 110 (shown as optional), internal timing sources (shown as optional), and cryptographic hardware (shown as optional). The verification controller 111 (e.g., proof engine 105) is configured to verify the event / task. The processing unit 106 drives the actuator 108 according to a task assignment 114, and the secure module records actuator-command sequences and internal status information in an execution log 110. The verification controller 111 (e.g., proof engine 105) may evaluate the execution log and generates a task verification proof 121, which may be provided to a resource monitor 124, coordinator 126, or ledger 128 via a local ledger instance 130.

[0113] In Fig. 3D, the tamper-proof secure module 104 is shown to operate with an internal sensor 118. An example of a tamper-proof secure proof engine may be implemented, e.g., as described in relation to Tables 1A, IB, etc.Attorney Docket No. 11855-002W01

[0114] Example Multiple Secure Module Observer Method #5. Fig. 3E shows an example verification sequence that employs multiple secure module observers (e.g., as remote sensors). In Fig. 3E, a target node 330 is configured to operate with a set of secure modules 104 (shown as 104a, 104b, 104c) as observer nodes 102 (shown as 102a, 102b, 102c). The target node 330 includes an actuator 108 configured to generate a physical output 116. Each observer node 102a, 102b, 102c of Fig. 3E is configured to observe the same physical output 116 from the same or different measurement perspectives to generate its respective sensed data 118 and verify and generate a proof, e.g., via its respective verification controller 111. Each generated proof 332 (shown as 332a, 332b, 332c) is provided back to the coordinator 126.

[0115] Indeed, in alternative embodiments, the target node 330 may be another observer node configured with an actuator. A multiple-sensor operation via sensor fusion may be performed, e.g., as described in relation to Figs. 4A and 4B.

[0116] Example Time-Aware Secure Module Method #6. Fig. 3F shows two examples for time-aware secure module configuration 300f. In Fig. 3F. the first of operation 300f includes receiving (342) tasks having a specified task window, executing (344, 346) an actuator command within the task window, comparing (348) the data output 118 and timing data in relation to verification parameters, and generating (350) and returning (352) task verification proof (e.g., 121) based on a verification operation. Fig. 3F shows a second of operation 300f (shown as 353) where a verification window is alternatively or additionally provided. In the second operation 353, the data 118 is collected (356) by the sensor 112 during the verification window'; otherwise, it is in waiting mode (354).

[0117] In some aspects, the techniques described herein relate to a method for verifying task execution in a distributed or centralized network, including: assigning, by a coordinator, task parameters and expected bounds to a node; executing, by a secure module within the node, the assigned task; eliciting and capturing, by a resource monitor, a physical output of the task; comparing, by a proof engine within the secure module, the physical output with the expected bounds; generating, by the proof engine, a cryptographic proof of correctness (e.g., signature or zero-knowledge proof); transmitting the proof to the coordinator; optionally recording a digest of the proof on a decentralized ledger; and verifying, by the coordinator, the proof and recording the verified result.

[0118] In some embodiments, the method includes computing, by the secure module, a deviation value between measured and expected results and signing a tuple of task identifier, measured value, target value, and pass / fail status.Attorney Docket No. 11855-002W01

[0119] In some embodiments, the method includes batch-processing a plurality of proofs and committing their digests to the ledger in a single transaction.

[0120] In some embodiments, the method includes verifying phase or timing alignment within a predefined tolerance.

[0121] In some embodiments, the method includes proof generation and verification that employ asymmetric cryptography, e.g., using Ed25519 signatures or equivalent schemes.

[0122] In some embodiments, the method includes task verification that is without reliance on a centralized authority.

[0123] In some embodiments, the method includes providing compensation that is automatically distributed to nodes whose proofs are verified as valid.

[0124] In some embodiments, the method includes generating a cryptographic proof by executing an attested Al inference model within the secure module to produce featurelevel or classification-level measurements of the physical output.

[0125] In some embodiments, the method includes employing a task window and a verification window that are defined with sub-millisecond precision relative to a global timing reference, wherein verifying the proof includes checking that the node's reported timing error is below a predetermined threshold. In some embodiments, the task window and verification window are defined relative to a shared epoch derived from timing beacons exchanged among nodes, and verifying the proof includes evaluating phase alignment or beat index consistency. In some embodiments, the task window and verification window are defined using coarse timing constraints expressed as minimum or maximum delays, event ordering, or deadlines based on local time, and verifying the proof includes determining whether the reported execution occurred within the specified constraints. In some embodiments, the task window and verification window are defined with high-precision timing relative to a global timing reference, including but not limited to millisecond- or submillisecond-level precision, and verifying the proof includes checking that the node’s reported timing error is below a predetermined threshold.

[0126] In some embodiments, the method includes generating the cryptographic proof further includes generating one or more timing-quality metrics indicating oscillator stability, drift correction applied, or timing-source confidence.

[0127] In some embodiments, the method includes generating, by the secure module, an execution attestation record that includes a hash of actuator commands, timestamps, and a status code, and signing the record with a key bound to an attested software image, whereinAttorney Docket No. 11855-002W01verification of the record provides assurance that the assigned task was executed as commanded, even in the absence of explicit physical output measurement.

[0128] In some embodiments, the method includes grouping sensor samples into windows, generating a cryptographic commitment for each window, and transmitting only a window-level proof unless a verifier issues a challenge requiring disclosure of individual samples.

[0129] In some embodiments, the method includes failure of a node to produce selectively requested samples or integrity metadata results in a reduction of credit, revocation of capability keys, or exclusion from subsequent tasks.

[0130] In some embodiments, the method includes deriving, by the secure module, a capability key from a node's root identity key based on an epoch identifier, credit state, or task policy, and authorizing task execution only upon verification of the capability key.

[0131] In some embodiments, the method includes deriving subordinate keys from a root identity key using a hierarchical deterministic derivation function, and uses the subordinate keys for signing task verification proofs, encrypting communication, or authorizing participation in distributed timing or audit protocols.

[0132] In some embodiments, the method includes authenticating sensor data from a semi-trusted external sensor using cryptographic integrity metadata and integrating the authenticated data with internal sensor measurements during the verification process.

[0133] Example Secure Execution-Only Operation

[0134] In certain embodiments, the system is configured to verify correct task execution without collecting sensor data 118 or measuring physical output 116. Rather, the secure module 104 is configured to (i) execute an actuator-control logic using authenticated task parameters, (ii) record actuator-command sequences and internal status information in an authenticated execution log, and (iii) evaluate the information within the proof engine 105 to generate a cryptographically signed execution attestation.

[0135] The execution-only pathway may include command-sequence hashes, local timestamps, software-measurement identifiers, error flags, or other internal metadata that collectively provide tamper-resistant evidence of correct task execution even in the absence of physical output 116 measurement. The operation may be applicable to digital tasks, low-risk or low-cost deployments, pre-characterized actuators, and hybrid systems where sensors are unavailable, impractical, or intentionally omitted. The same secure module 104 and proof engine 105 as described in relation to Figs. 1A - 1C may be employed, allowing execution-Atorney Docket No. 11855-002W01only atestations to coexist with or replace sensor-based task verification proofs depending on deployment requirements.

[0136] Processes. Behaviors, and Timing Components

[0137] Synchronization Mechanism. Processes can enable coordinated timing, shared state, or temporal correlation across nodes 102. In different embodiments, a synchronization mechanism may be employed to provide (i) globally referenced time, (ii) relative phase alignment without absolute time, or (hi) coarse or asynchronous timing sufficient only to order events or enforce minimum / maximum delays.

[0138] Timing reference / Epoch. A shared time or phase reference may be used for synchronization of timing-dependent tasks. In some embodiments, this corresponds to an absolute timebase (for example, UTC or GNSS time); in others, it is a relative epoch or phase marker used only to align periodic behavior such as beats, pulses, or frame boundaries.

[0139] Task window (132). The interval during which the actuator 108 must produce the commanded output is referred to as a task window 132. In some embodiments, the task window 132 is defined with sub-millisecond precision; in other embodiments, it may be specified only coarsely (for example, “within the next 5 seconds”) or implicitly via event ordering. Fig. IB shows an example of the task window 132 in relation to the verification window 134.

[0140] In some embodiments, the task window and verification window are defined with high-precision timing relative to a global timing reference, including but not limited to millisecond- or sub-millisecond-level precision, and verifying the proof includes checking that the node’s reported timing error is below a predetermined threshold.

[0141] Verification window (134). The time interval during which sensor measurements must be collected for verification is the verification window. In some embodiments, the verification window7is tightly aligned with the task window 132; in others, it may span a broader interval or be defined relative to observable events (for example, “after receipt of trigger X but before deadline Y”) without requiring a globally shared clock.

[0142] Timing Tightness, Timing Regime. Timing tightness and timing regime refer to the degree of timing precision required for task execution and verification. The system supports a range of timing regimes, including (i) globally referenced time, (ii) relative phase alignment, and (iii) coarse or asynchronous timing without a shared clock. Task window s 132 and verification windows 134 can apply across all regimes. In tightly synchronized embodiments, they (132. 134) may correspond to precise absolute or phase-aligned intervals, while in coarse or asynchronous embodiments, they (132, 134) may be defined using localAttorney Docket No. 11855-002W01timestamps, counters, observable triggers, or ordering constraints. In each regime, the proof engine (105) may incorporate timing metadata sufficient for a verifier to determine whether the node 102 satisfied the timing requirements applicable to that task.

[0143] Execution-Only Verification Mode. Execution-only verification mode refers to an embodiment in which the system verifies correct task execution without measuring physical output 116. The secure module 104 may (i) generate actuator-control signals according to the task parameters, (ii) record internal execution metadata, (iii) evaluate this metadata against verification parameters, and (iv) produce a cryptographically signed execution attestation. The mode can provide high assurance of correct task execution even when sensors are not present, cannot measure the output, or are unnecessary for the assigned task.

[0144] Drift Correction Mechanism. Drift correction mechanism is a logic that can adjust local timing to maintain alignment with a timing reference or to bound clock error over the duration of one or more tasks.

[0145] Proof Validation Mechanism. Proof validation mechanism is a component (often the coordinator 126 or ledger 128) that verifies the authenticity and correctness of submitted proofs, including optional checks on timing consistency, ordering, or allowed skew.

[0146] Co-Located Actuator and Sensor Embodiments

[0147] In some embodiments, the system ensures physical measurement integrity by co-locating the actuator 108 and sensor 112 within a secure module 104, such that the sensor 112 is exposed only to the physical output produced by the actuator 108 through a controlled, internal pathway. The arrangement prevents an adversary from injecting, spoofing, masking, or otherwise manipulating the Sensor’s measurements without defeating the tamper-resistant enclosure. Co-location thereby couples cryptographic proof generation with a trustworthy physical measurement boundary.

[0148] Co-Located actuator and sensor configurations can ensures that (i) the sensor 112 measures only the physical output of the actuator 108, (ii) the measurement path cannot be bypassed or electrically spoofed from outside the secure module 104; (iii) cryptographic proofs generated by the proof engine (105) correspond to actual physical behavior; and (iv) measurement fidelity is protected by mechanical, optical, or electromagnetic constraints rather than software alone. Examples of co-located actuator and sensor include, but are not limited to, light-based actuator and mechanical, servo, and robotic actuator.

[0149] Table 1 A shows descriptions for light-based actuator configurations.Attorney Docket No. 11855-002W01Table 1ALight- based DescriptionactuatorconfigurationPartial Reflector / Secure module 104 may include (i) a light emitter or LED array, (ii) Beam-Splitter an optical window for emission to the environment, (iii) a partial reflector, beam splitter, or light tap positioned to divert a small, calibrated fraction of the emitted light toward an internal optical sensor 112, or a combination thereof. The majority' of the light may exit the module to illuminate the environment, while a minority fraction is directed to the internal sensor 112 through a secure, internal path. Because the tap resides entirely within the tamperresistant enclosure, no external light can spoof the sensor 112.Reflective The actuator 108 and sensor 112 may be positioned inside a reflective Integrating Cavity optical cavity with a single external aperture. The actuator 108 can illuminate the cavity, a portion of which exits through the aperture. The internal sensor 112 can measure illumination from within the cavity, ensuring that observed light corresponds to the actuator’s output and cannot be meaningfully overridden by external light sources.Package- The actuator 108 may include a light source package that includes an Integrated Monitor integrated monitor photodiode. The photodiode can receive a back- Photodiode reflection or internal emission proportional to output brightness or spectral content. The secure module 104 can read this internal signal as the ground-truth measurement of optical output. Because the photodiode is inside the sealed package, external optical spoofing is prevented.

[0150] Table IB provides descriptions of mechanical, servo, and robotic actuator configurations.Table IBExample DescriptionConfigurationAttorney Docket No. 11855-002W01Encoded Output The secure module 104 can enclose the motor, gearing, and the Shaft output shaft. An encoder (optical, magnetic, Hall-effect, or potentiometric) may be rigidly affixed to the shaft inside the secure module 104. Only the mechanical interface at the shaft’s end may extend outside the module. Any external movement necessarily results in a corresponding internal encoder measurement, ensuring correct physical coupling.Magnetic Coupled A magnet may be attached to the internal portion of the output shaft, Encoder while a magnetic field sensor inside the secure module 104 detects rotational or positional changes. The system thereby provides secure position sensing even when the shaft penetrates the housing boundary.Torque or Force For actuators that apply force or torque, the secure module 104 may Sensing include strain gauges, torque rings, or motor-current-based torque estimators. The Sensors reveal whether the actuator had attempted motion (torque applied), achieved motion (encoder change), or encountered obstruction (high torque + low displacement).

[0151] Technical Benefits of Co-Location. Co-location of actuator 108 and sensor 112 inside a secure module 104 can offer (i) physical authenticity: the sensor 112 cannot be fed synthetic or externally injected signals, (ii) measurement integrity: cry ptographic proofs reflect actual, unspoofed measurements, (iii) tamper resistance: spoofing or masking attempts require breaching the physical enclosure, and (iv) cross-domain applicability: valid for optical, mechanical, acoustic, thermal, fluidic, and electromagnetic actuators.

[0152] Hardware Trust Boundaries and Multi-sensor Fusion

[0153] Figs. 4A and 4B show examples of hardware trust boundaries and multi-sensor fusion configuration, in accordance with an illustrative embodiment. In certain embodiments, the system can incorporate multiple sensors operating at different trust levels and fuse their measurements within a secure module 104 to generate tamper-resistant sensor data 118. The secure module 104 can enforce hardware-level trust boundaries, cry ptographically authenticate semi-trusted external sensors, and combine multimodal sensor data to enhance measurement integrity and detect adversarial manipulation.Attorney Docket No. 11855-002W01

[0154] In some embodiments, the secure module or associated sensor hardware includes a physically unclonable function (PUF), enabling device identity’, key derivation, or challenge-response authentication rooted in unique physical characteristics of the hardware. The PUF may generate or protect cryptographic keys used for proof signing, sensor-data authentication, or timing-proof generation, thereby strengthening hardware-level trust boundaries and providing resistance against cloning or key extraction.

[0155] Fig. 4A shows an example trust boundary architecture operation in accordance with an illustrative embodiment. In Fig. 4A, a fully trusted sensor or semi-trusted sensor may be employed. In Fig. 4A, sensors 118 (shown as 402) are shown located entirely within the secure module 104, partially inside the secure module 104 with protected electrical pathways, or outside the secure module 104 but cry ptographically bound to the internal proof engine (105). The secure module 104 may employ a fusion engine 404. This can allow the system to incorporate both trusted and semi-trusted measurements while maintaining end-to-end verifiability'.

[0156] A fully trusted sensor can reside entirely inside the secure module 104, with its electrical or optical measurement path inaccessible to adversaries. Internal sensors may include and are not limited to, monitor photodiodes, cameras, magnetic encoders, current sensors, inertial measurement units (IMUs), microphones, or photodiodes connected only through optically sealed apertures, or a combination thereof.

[0157] A semi-trusted sensor can reside outside the secure module 104. but is connected through a cryptographically authenticated channel. The secure module 104 may authenticate semi-trusted sensor data using at least one: (i) digital signatures generated by a secondary' secure module 104, (ii) message authentication codes (MACs) using pre-shared keys (406). (iii) secure timestamping synchronized to the task windoyv 132 or verification window 134, or challenge-response exchanges initiated by the internal proof engine (105). Semi -trusted sensors alloyv nodes 102 to incorporate higher-resolution or yvider-field measurements (for example, cameras, spectral sensors, or environmental sensors) without requiring that the full sensor stack be physically embedded within the secure module 104.

[0158] Trust Boundary Enforcement. In Fig. 4A, the secure module 104 can enforce trust boundaries by performing at least one of the folloyving: (i) accepting untrusted or semitrusted data only if accompanied by integrity' metadata (signature, MAC, timestamp) (406), (ii) rejecting data that fall outside allowed timing skew, ordering consistency, or nonce / counter windows, (iii) cross-checking external data against internally measured quantities when available, and (iv) computing deviation metrics between multiple sensorAttorney Docket No. 11855-002W01modalities to detect spoofing, failure, or environmental interference. The layered approach can prevent adversaries from spoofing external sensors unless they also compromise the cryptographic identity of the semi-trusted sensor or defeat the trust boundary protocol.

[0159] Multi-Sensor Fusion Within the Secure Module. In some embodiments, multi - sensor fusion may be performed by combining measurements from two or more sensors selected from the group consisting of: optical sensors. IMUs, electrical sensors, magnetic encoders, microphones, or environmental sensors. In Fig 4B, the secure module 104 is configured to perform multi-sensor fusion, via a fusion engine 404 (shown as 404’) configured to combine data from multiple sensors (internal or external) to produce a single fused sensor data record used by the proof engine (105).

[0160] Table 2A provides examples of fusion modalities.Table 2AExample Sensor for DescriptionFusionOptical + IMU Verify that visual movement matches inertial movement. Optical + electrical Confirm that the measured light output corresponds to the commanded current or PWM duty' cycle.Optical + audio Verify beat-synchronized lighting using both flicker and acoustic features.IMU + magnetic encoder Validate mechanical motion using redundant rotational or torque measurements.

[0161] Fusion algorithms (e.g., via 404’) may include weighted averaging, confidence scoring, majority voting, threshold logic, or model-based estimators executed inside the secure module 104. Fused sensor outputs are incorporated into verification parameters and used when generating task verification proofs.

[0162] Cross-Module Sensor Fusion. In distributed deployments, nodes 102 may share encrypted sensor summaries or semantic features with neighboring nodes 102 or a coordinator 126. The secure module 104 may use the additional data streams to detect (i) local spoofing attempts, (ii) sensor occlusion or obstruction, (iii) inconsistent timing, (iv) faulty actuators, (v) deviations from quorum consensus among observers, or (vi) a combination thereof. Cross-module fusion can provide robust multi-observer validation inAttorney Docket No. 11855-002W01environments where environmental factors, obstructions, or line-of-sight conditions may prevent a single sensor 112 from reliably measuring physical output 116.

[0163] Physical Anti-Spoofing and Sensor-Integritv Architecture

[0164] In addition to cryptographic protections and multi-sensor fusion, the system may employ physical, optical, mechanical, electromagnetic, and structural anti-spoofing architectures to ensure that sensor data 118 used for task verification proofs originates from genuine physical output produced by the actuator 108. These embodiments can prevent external signals, environmental noise, or adversarial interference from corrupting measurement integrity.

[0165] In certain embodiments, the secure module 104 employs physical, optical, electromagnetic, mechanical, thermal, acoustic, and structural anti-spoofing architectures to ensure that sensor data 118 used for verification derives solely from genuine actuator output. The embodiments may include baffled optical channels, EMI shielding, mechanical isolation, thermal conduction paths, waveguide-below-cutoff geometries, inertial cross-checking, and multi-physics fusion. Together, the mechanisms can prevent adversarial injection, mimicry, or masking of sensor measurements and enhance the integrity of task verification proofs.

[0166] In some embodiments, the secure module 104 is enclosed within a tamperresistant housing incorporating protections such as epoxy potting, metallic shielding, conductive or optical tamper-mesh layers, pressure or vacuum tamper switches, or break-loop circuits. These mechanisms may detect or prevent physical intrusion and protect sensor pathways, actuator-control interfaces, cryptographic keys, and verification logic against probing, drilling, milling, or external manipulation.

[0167] Fig. 5 shows physical anti-spoofing structures 502, e.g., optical baffling, EMI shielding, mechanical isolation, thermal pathways, and waveguide-below-cutoff geometries, any of which may reside inside or around the secure module 104, being employed to ensure sensor integrity’. In Fig. 5, the output 116 of an actuator 108 is provided to one of optical baffling 502a, EMI shielding 502b, mechanical isolation 502c, thermal pathways 502d, waveguide-below-cutoff geometries 502e. or a combination thereof.

[0168] Table 3 provides a description of the physical anti-spoofing configurations.Table 3Example Physical DescriptionAnti-SpoofingAtorney Docket No. 11855-002W01Optical Anti-Spoofing The secure module 104 may incorporate optical geometries to Architectures (502a) ensure only actuator-generated photons can reach the internal sensor. These may include (i) baffled optical channels, which eliminate off-axis light injection, (ii) labyrinthine light traps, which prevent direct external illumination, (iii) blackened or absorptive surfaces to suppress internal reflections, (iv) bandpass or notch filters matched to the Actuator’s emission spectrum, (v) polarization filters that pass only actuator-aligned polarization states, or (vi) waveguide-below-cutoff structures that permit actuator-generated wavelengths but attenuate others exponentially The structures can ensure that adversaries cannot illuminate the sensor externally with a laser, flashlight, or structured light source to mimic actuator output.Electromagnetic The secure module 104 may include RF and EMI shielding (RF / EMI) Antidesigned to prevent injection of electromagnetic paterns that Spoofing (502b) could mimic actuator behavior or sensor output. Techniques may include (i) Faraday shielding, blocking external RF fields from coupling into sensor pathways, (ii) grounded metallic enclosures, reducing susceptibility to radiated or conducted EMI, (iii) waveguide-below-cutoff RF apertures, allowing DC airflow or illumination while blocking RF injection, (iv) low- pass, high-pass, or band-pass filter networks integrated directly on sensor interconnects, (v) current-balanced differential signaling to resist EM injection atacks. The embodiments can prevent atackers from spoofing sensor readings through RF stimulation, EM pulses, or crosstalk injection.Mechanical and For mechanical or robotic actuators, the secure module 104 may Kinematic Antiincorporate structures ensuring that only genuine mechanical Spoofing (502c) motion produced by the actuator is measurable. The antispoofing structures may include (i) torque or strain rings positioned wholly inside the secure module 104, (ii) coded mechanical linkages (e.g., keyed shafts) with one-way coupling; internal encoders whose optical or magnetic paterns are notAttorney Docket No. 11855-002W01externally visible, (iii) sealed bearings or flexure geometries that transmit motion only through the attested mechanical interface, and / or (iv) overload or stall sensors to detect unnatural torque signatures indicative of spoofing or forced manipulation. The designs can prevent an adversary from externally rotating a shaft, vibrating the housing, or inducing apparent motion that the actuator did not produce.Acoustic and For acoustic or vibrational sensing embodiments, anti-spoofing Vibrational Antiarchitecture may include (i) acoustic waveguides that prevent Spoofing (502e) external injection at resonant frequencies, (ii) Helmholtz or band-stop cavities tuned to suppress likely spoofing frequencies, (iii) triangulated sensor arrays within the secure module 104 to detect unnatural directi onality. or (iv) inertial cross-checks using IMUs to verify that acoustic events correspond to actuator activity. The designs can prevent adversaries from playing recorded actuator sounds or injecting acoustic energy.Thermal and Infrared Where thermal or IR sensing is used, the secure module 104 Anti-Spoofing (502d) may incorporate (i) sealed thermal conduction paths between actuator 108 and sensor 112, (ii) multi-layer insulation (MLI) preventing external heating from reaching internal sensors, (iii) spectral filters restricting infrared wavelengths to those produced by the actuator, (iv) temperature-gradient detection, ensuring thermal patterns match expected actuator heat distribution. The mechanisms can prevent spoofing with heat lamps, hot-air guns, or IR sources.

[0169] In addition to the tamper detection mechanisms described above, structural isolation and tamper-detection may be employed such as (i) epoxy-filled or potting-filled cavities, preventing access to sensor pathways, (ii) conductive-mesh tamper shields detecting enclosure penetration attempts, (iii) fiber-optic or conductive break-loops embedded in the housing, (iv) pressure or vacuum seals, detecting drilling, prying, or milling, and / or (v) mechanical resonant signatures, monitoring for abnormal vibration patterns consistent withAttorney Docket No. 11855-002W01tampering. These can provide early detection of physical attacks aimed at bypassing or spoofing internal measurements.

[0170] In some embodiments, combined multi-physics anti-spoofing may be employed, where measurements from different physical domains are combined to validate actuator output. Examples may include (i) optical + thermal: to verify both light emission and heat production, (ii) mechanical + magnetic: to confirm rotational motion with multiple modalities, (iii) optical + electrical: to verify’ actuator drive current corresponds to emitted light, (iv) RF + IMU: to confirm drone strobe timing with inertial and radio signals. Crossdomain correlation can raise the cost of spoofing, as an adversary must falsify multiple unrelated physical signatures simultaneously.

[0171] Example Operation

[0172] Figs. 6A - 6F each show an example operation 600a, 600b, 600c, 600d, 600e, 600f for a set of nodes 102 (shown as 102a, 102b, 102c) of any one of Figs. 1A - 1C, in accordance with an illustrative embodiment.

[0173] Example Operation #7. Fig. 6A shows an example operation 600a for a system comprising nodes 102, secure modules 104, resource monitors 124, ledger integration, and value exchange mechanisms. Alternative embodiments may be implemented for multi-tier coordinators, hierarchical node clusters, sensor fusion modules, or distributed proof engines, which may be selected depending on deployment size or network topology.

[0174] In Fig. 6A, the coordinator 126, node (102a, 102b.... 102c) with its respective secure module 104 (including proof engine (105)), resource monitor 124, optional proof engine (105), and optional ledger 128 are shown performing task assignment 114, execution to generate a physical output 116, measurement to generate sensor data 118, proof generation by the proof engine 105, verification 602, and (optional) on-chain commit 604.

[0175] Fig. 6A shows an optional synchronization mechanism that may be employed, e.g., as described in relation to Fig. 9, that can provide timing inputs 604 to each of the nodes (102a, 102b,..., 102c).

[0176] Example Operation #2. Fig. 6B shows an example operation 600b for a node 102 (among others described herein). In Fig. 6B, the node 102 is shown comprising a secure module 104, processing unit 106, actuator 108, optional internal and external sensors 112, and a proof engine 105, the proof engine 105 in combination w ith the other components being configured to generate task verification proofs (e.g., 121) based on sensor data 118, execution logs 110, or timing metadata. The embodiment shown in Fig. 6B may be employed for both sensor-based verification and secure execution-only attestations.Attorney Docket No. 11855-002W01

[0177] In addition to sensor-based verification, the node 102 can perform secure execution-only mode. In the configuration, the processing unit 106 within the secure module 104 can (i) generate actuator commands according to the task assignment (e.g., 114), (ii) record internal status information and timing metadata in an authenticated execution log, and (iii) forward the information to the proof engine 105. The proof engine 105 can evaluate the execution log against verification parameters and produce an execution attestation without requiring any physical output measurement. The embodiment provides tamper-resistant assurance of correct task execution for digital, low-risk, or pre-calibrated actuators.

[0178] Example Operation 3. Fig. 6C shows an example operation 600c for an internal proof engine pipeline. In Fig. 6C, the internal proof engine pipeline is shown operating within a secure module 104. Inputs may include sensor data 118, execution logs, timing metadata, multi-sensor fused data, and Al-derived semantic features. The proof engine 105 is configured to perform deviation calculation (612), semantic evaluation (614), timing checks (616), execution-attestation evaluation (618), commitment construction (620), and cryptographic proof generation (622).

[0179] As a non-limiting example, the deviation calculation (612) can be based on a comparison or deviation calculator, e.g., as described in relation to Fig. 7A. As anon-limiting example, semantic evaluation (614) may be performed via pattern analysis, classification analysis, or feature-matching analysis. In some embodiments, the operation is performed using a trained Al model, e.g., as described in relation to Figs. 8A - 8C. As a nonlimiting example, execution-attestation evaluation (618) may be performed using features, e.g., as described in relation to Tables 5A and 5B. As a non-limiting example, timing consistency checks (616) may be performed using operations, e.g., as described in relation to Fig. 9A. As a non-limiting example, cryptographic proof generation (622) can include performing proof signing and capability control as described herein.

[0180] Example Operations #4 and #5. Figs. 6D and 6E each show an example operation 600d, 600e for a selective-audit proof pipeline by a verifier 640. Fig. 6D shows the operation for a window-level commitment, e.g., as described in relation to Figs. 7C. Fig. 6D shows a batch operation for the same.

[0181] In Fig. 6D, the selective-audit proof pipeline operation 600d may be performed for high-frequency sensor proof generation by a secure module 104 that is configured to produce authenticated per-sample records and compute window-level commitments (e.g., 620), to generate a task verification proof (e.g.. 121). Verifiers 640 receives (644) the task verification proof (e.g., 121) and may issue selective audits (646)Attorney Docket No. 11855-002W01requesting (648) disclosure of specific samples and integrity' metadata, enabling tamper-evident verification (649) with reduced bandwidth. An example operation of the selective audit is described in relation to Fig. 7C.

[0182] Example Operation #7. Fig. 6F shows an example operation 600f for an execution-only attestation pipeline. In Fig. 6F, the execution-only attestation pipeline 600f may be performed by a secure module 104 that is configured to (i) execute a task, (ii) generate actuator-command sequences (660), (iii) record internal status or timing information (662), and (iv) produce an attested execution log (666) without requiring physical-output verification. The proof engine 105 may convert the execution events, command traces, and software-measurement metadata into a cryptographically signed execution attestation 668. As shown in Fig. 6F. the actuator-command sequences 660 may be PWM outputs, drive signals, state transitions, or other time-series data. The recorded internal status or timing information 662 can include start and end of timers, error codes, counter values, or other internal computed or measured data for the node or a connected device.

[0183] Task Verification Implementation

[0184] Figs. 7A - 7C each show example verification operations 700a, 700b, 700c for the system and method described herein, in accordance with an illustrative embodiment. Fig.7A shows an example operation#!, Fig. 7B shows a pseudocode for the verification operation, and Fig. 7C shows an example operation #2.

[0185] The verification operation 700a may include at least one of: (i) hardwarebased verification via TEEs, secure module 104s, or equivalent isolation mechanisms that ensure tamper-resistant execution, (ii) sensor 112-based validation of physical output 116 using authenticated sensor data 118, (iii) cryptographic proof generation performed by the proof engine (105), including signatures, attestations, or ZKPs, and (iv) optional, ledger integration for decentralized record-keeping, audit, or compensation.

[0186] Table 4A shows an example verification.Table 4AA photodiode measures 605 lux ± 3 %.The secure module 104 computes deviation = |605 - 600| / 600 = 0.008 < 0.05. Proof P = Sign(sk_module, {task_id, deviation, pass}).

[0187] Fig. 7A shows an example task verification operation 700a. In Fig. 7A. the operation 700a includes (i) assignment, (ii) secure execution, (iii) measurement, (iv) comparison + proof, (v) verification, (vi) optional on-chain commit, and (vii) record. TheAttorney Docket No. 11855-002W01verification flow 700a can support a secure execution-only variant in which steps (e.g., Steps 3-4 (physical sensing)) are omitted and the secure module 104 instead evaluates an authenticated execution log reflecting the actuator commands and internal status information produced during Step 2.

[0188] In Fig. 7A, the secure module 104 of a node 102 is shown receiving (702) a task from a coordinator 126. The node executes (704) the task, elicits (706) a physical output 116, measures (708) sensor data, and performs a comparison / verification operation 710 to generate a proof. The generated proof is transmitted (712) back to the coordinator 126, which may optionally commit (714) the proof to a ledger.

[0189] Pseudocode of Task Verification Loop. Fig. 7B shows an example pseudocode 700b for performing the verification process, e.g.. for Figs. 7A or 7C. The pseudocode corresponds to steps 2-6 (704, 706, 708, 710, 710) and highlights a core operation a Step 5 (710) to perform comparison + proof generation. The operation 710 may be invoked when the task is performed, and a deviation (referred to as “dev”) is compared to a bound or tolerance as described herein. The operation 710 may then invoke a proof data function that includes the task identifier and task target.

[0190] Secure Module Proof Path. Referring to Fig. 7A, the secure module 104 may include an internal proof engine (105) that executes the comparison algorithm within an attested environment. An example workflow may include (i) the module receiving task parameters (e.g.. target lux = 600. tolerance = ±5 %) and a unique task identifier, (ii) the resource monitor 124 reporting a measured value (e.g., 605 lux), (iii) the proof engine (105) computing deviation (e.g., deviation = |605 - 600| / 600 = 0.008 (< 0.05 threshold)), and (iv) the module then generating a proof (e.g., Proof = Sign(sk_module, {task_id, measured = 605, target = 600, pass = true}). The coordinator 126 can verify the signature and, optionally, submit the digest to the ledger. The example demonstrates the step-by-step process of measurement, comparison, and proof generation.

[0191] Down-sampled Sensor Proofs. Commitments, and Challenge Protocols

[0192] In many embodiments, sensors 112 may generate measurements at a substantially higher rate than is practical for real-time verification or ledger submission. To ensure scalabil ity while maintaining verifiability, the system employs a hierarchical proof structure based on (i) high-frequency authenticated samples generated inside the secure module 104, (ii) downsampled or aggregated summaries, and (iii) optional challengeresponse mechanisms that permit selective validation of underlying data.Attorney Docket No. 11855-002W01

[0193] Fig. 7C shows an example selective auditability of high-frequency sensor proofs 720. In Fig. 7C, the secure module (e.g.. 104) provides a selective-auditability mechanism (722, 724, 726) that allows nodes 102 to generate authenticated sensor samples at high frequency while submitting only compact, window-level proofs under normal operation. Verifiers can subsequently request (728) full or partial disclosure of high-frequency samples to validate the integrity of summaries or to investigate suspicious behavior, without requiring continuous transmission of raw sensor data 118.

[0194] High-Frequency Sample Authentication (722). Within the secure module 104, each sensor sample s, is authenticated using a fast cryptographic primitive such as HMAC or a lightweight signature and is associated with (i) a monotonically increasing counter, (ii) a local timestamp, (iii) the sensor identifier, and (iv) the current task identifier.

[0195] Table 4B shows an example per-sample record may be stored internally. In Table 4B, the tag is a MAC or signature generated inside the secure module 104.Table 4B| n = { sample value, counter, timestamp, sensor id. task id, tag } |

[0196] Window-Level Commitments (724). To support efficient verification, the secure module 104 may group samples into windows (for example, fixed-duration windows or fixed-sample-count windows) and compute (724) a cryptographic commitment such as (i) a concatenation hash over all r„ (ii) a Merkle root over the per-sample records, and / or (iii) a chained-hash accumulator representing the ordered sample stream. The secure module 104 may also compute summary statistics (e g., 725) such as min, max, mean, variance, or threshold-based flags. The secure module 104 may then generate a window-level proof.

[0197] Table 4C shows an example window-level proof. This proof may be transmitted to the coordinator 126 or ledger 128.Table 4CWindowProof = {task_id,window_index,stats,commitment: C_W} signed by sk_moduleAttorney Docket No. 11855-002W01

[0198] Challenge-Based Audit Mechanism (728). If a verifier detects anomalies or wishes to ensure that summaries were computed honestly, the verifier may issue a selective audit challenge (728) requesting: (i) specific sample indices or ranges, (ii) Merkle paths or hash links binding these samples to the window^ commitment, or (iii) recalculated statistics. Upon receiving the challenge, the secure module 104 may reveal the requested samples and their integrity metadata. The verifier (730) can (i) reconstruct the commitment C_W, (ii) validate tags / MACs, (iii) check ordering, and (iv) recompute summary statistics (e.g., 725) to ensure consistency with the previously submitted window-level proof.

[0199] Misbehavior Detection and Economic Enforcement. A node 102 that deletes outliers, reorders data, tampers with samples, or falsifies summary statistics (e.g., 725) will fail a challenge verification. The system may then: (i) reject the window-level proof, penalize the node’s credit score, revoke or reduce capability keys, require increased audit frequency, and / or remove the node 102 from participation. The operation may be performed as described in relation to Figs. 12A - 12D.

[0200] Selective auditability can thus ensure that nodes 102 remain accountable even when real-time verification is down-sampled, creating a tamper-evident bridge between high-frequency measurement and scalable network-level validation.

[0201] Benefits of Selective Auditability. Selective auditability can provide (i) scalability, by avoiding continuous transmission of raw sensor data 118, (ii) strong integrity, via cryptographic commitments and authenticated samples, (iii) flexibility, allowing verifiers to audit only when necessary, (iv) robustness, detecting adversarial suppression or manipulation of sensor values, and (v) compatibility with batch verification, capability keys, and distributed coordination. Selective auditability can therefore enable secure, scalable, and economically meaningful verification in dense, high-frequency sensing deployments.

[0202] Fig. 7C shows an example of operation 720 with selective auditability of high-frequency sensor proofs. In Fig. 7C, a secure module 104 generates authenticated high-frequency sensor samples and computes a window -level commitment. Under normal operation, only a Window-Level Proof is submitted. Upon receiving a challenge audit, the secure module 104 reveals specific samples and Merkle paths that allow the verifier to recompute and validate the commitment.

[0203] High-Frequency Sample Generation. The secure module 104 may generate authenticated sample records at high frequency using a fast cryptographic primitive such as HMAC or a lightweight signature scheme. For each sensor sample Si. the secure module 104Attorney Docket No. 11855-002W01may generate an authenticated record per Table 4D. In Table 4D, the tag is a MAC or signature over the record.Table 4DTi = { sample_value, local_counter, sensor_id, task_id, tag }

[0204] All such records remain inside the secure module 104 or in a protected buffer. The high-frequency proofs can establish (i) authenticity of each sample, (ii) ordering through monotonic counters, and (iii) protection against deletion, reordering, or injection.

[0205] Window-Level Commitments and Summaries (e.g., 724). To limit bandwidth and verification cost, samples may be grouped into windows, such as fixed sample counts or sensor-defined intervals. For each window W, the secure module 104 can compute a cryptographic commitment, e g., as a concatenation hash (e g., C_W = Hash(ri || r? ||... || rn)) or a Merkle root over the set {n}.

[0206] The secure module 104 can compute summary statistics (725), such as minimum, maximum, mean, variance, threshold satisfaction (e.g., pass / fail), drift or trend indicators, and / or number of samples in the window.

[0207] Table 4E shows an example window summary (e.g., 725). The secure module 104 or processing unit 106 may generate a signed window-level proof attesting to these values.Table 4Esummary _W = {task_id,window start,window end,stats,commitment: C_W

[0208] Hierarchical or Batch Verification. Coordinators 126 or verifiers may operate at a lower frequency than the sensors. They may verify only the signed summaries rather than each individual sample. This can provide reduced computational load, reduced network traffic, and scalable verification for high-rate sensors. If a proof indicates misbehavior or lowAttorney Docket No. 11855-002W01quality (e.g., summary out of the expected range), the coordinator 126 may trigger a challenge protocol.

[0209] Challenge Protocol. To deter or detect misbehavior when verification is downsampled, the system may support selective audit challenges (e.g., 728). A coordinator 126, ledger component, peer node 102, or automated monitor may request that the node 102 reveal: (i) some or all high-frequency authenticated sample records {n} for a specific window IF, (ii) Merkle paths or other proofs linking {n} to the commitment C_W, (iii) recalculated or raw statistics derived from the underlying samples; and / or (iv) timing data, drift data, or additional metadata required for verification. The secure module 104 may respond (e.g., 734) by releasing the requested data along with cryptographic integrity proofs. Verifiers may recompute (i) MACs / tags for each underlying sample, (ii) the window commitment (hash or Merkle root), (iii) summary statistics (e.g., 725), and / or (iv) deviations from expected sensor behavior. A failed challenge can result in the node being marked as misbehaving and may trigger: (i) rejection of the summary proof, (ii) immediate reduction or slashing of the Node’s credit or capabilities, (iii) denial of future capability keys, and / or (iv) or heightened scrutiny for subsequent tasks, e.g., as described in relation to Figs. 12A - 12D.

[0210] Benefits of Downsampling and Commitment-Based Verification. This design can enable high-frequency sensing with low-frequency verification, proofs that remain compact and efficiently checkable, selective audits that expose misbehavior, robust scaling to thousands of nodes 102 generating heavy sensor data, and / or strong guarantees of auditability without mandating constant global verification. This downsampling architecture also integrates with the credit and capability mechanisms, e.g., as described in relation to Figs. 12A - 12D, where nodes 102 that submit faulty summaries or fail challenge audits may lose future capabilities, thereby discouraging attempts to exploit the lag between proof generation and batch verification.

[0211] Attested Code Identity and Measured Software Execution

[0212] In certain embodiments, the secure module 104 can provide a cryptographic attestation proving that task verification proofs were generated by a specific, measured verification software image executing within a tamper-resistant environment. This attestation can bind the verification key to the measured code hash, preventing altered or unauthorized software from producing valid proofs and thereby ensuring the integrity of the verification process. The secure module 104 can ensure not only that sensor data 118 is authentic, but also that the software used to produce verification results is itself characterized as authenticated, measured, and unmodified. This can prevent the unauthorized or altered software fromAttorney Docket No. 11855-002W01generating task verification proofs, even if an adversary obtains hardware access to the node 102.

[0213] In some embodiments, the secure module 104 includes a hardware root of trust, such as a Trusted Execution Environment (TEE), secure enclave, Trusted Platform Module (TPM), or a physically unclonable function (PUF) that provides device-unique key material. These components may generate or protect attestation keys, sealing keys, or capability keys, and may ensure that timing proofs, sensor-data authentication, and verification operations originate from hardware-bound, cryptographically verifiable roots of trust.

[0214] The operation can establish a cryptographic binding between at least one of: the identity of the secure module 104, the cryptographic hash of the software image executed, the key used to generate task verification proofs, or a combination thereof. The operation may be based on (i) code measurement and attestation, (ii) execution of the measured software image, and (iii) protection against software tampering, and (iv) re-attestation and epochal binding. This operation does not assert that the measured software image is “correct” in a semantic or functional sense. Rather, the operation ensures that only the approved, attested software image was executed, and that proofs originate from that image.

[0215] Code Measurement and Attestation. In one embodiment, the secure module 104 may include a hardware root of trust such as a Trusted Execution Environment (TEE), Trusted Platform Module (TPM), secure enclave, or equivalent. During boot or initialization, the secure module 104 may (i) compute a cryptographic hash of the verification software image, (ii) verify that this hash matches an approved or expected value, and / or (iii) bind a signing key or sealing key to this code measurement.

[0216] Table 5A shows an example attestation structure. The attestation can convey to the coordinator 126, ledger 128, or any verifying entity.Table 5Aattest = {module id.measured_code_hash,public key: pk module,configuration_metadata,timestamp} signed by attestation rootAttorney Docket No. 11855-002W01

[0217] Execution of the Measured Software Image. During execution, the secure module 104 may (i) run only the measured and approved software image, e.g., as described in relation to Fig. 6F, (ii) collect sensor data 118 through trusted internal pathways, (iii) perform comparison and evaluation logic defined by the image, and (iv) generate task verification proofs signed using skjnodule, the private key bound to the measured software. Thus, a valid task verification proof can imply that the proof was generated by the software image whose measured hash is H, executing within this authenticated secure module 104. This can guarantee code identity and integrity, not code correctness.

[0218] The protection can provide against software tampering. Because the signing key may be tied to a specific measured software hash, a different software hash can be produced by (i) modification of the verification logic, change of comparison thresholds, bypass of sensor data 118 checks, or injection of fabricated data. This would break the attestation and prevent malicious code from generating valid proofs.

[0219] Optional Re-Attestation and Epochal Binding. In some embodiments, the secure module 104 may periodically re-attest its software image, rotate or derive new ephemeral keys, or check whether the measured code hash is still present in an approved policy list on the ledger. This can ensure that nodes 102 execute up-to-date, approved verification software.

[0220] Integration With Other System Components. The attested execution mechanism can reinforce and operate with any one of the following operations described herein, including down-sampled sensor proofs as described in relation to Fig. 7C, challenge protocols as described in relation to Fig. 7C, credit and capability mechanisms as described in relation to Figs. 12A - 12D, and / or synchronization and timing as described in relation to Figs. 9A- 9B.

[0221] Down-sampled sensor proofs, as described herein, allow a verifier to know summarization / aggregation logic has not been altered. Challenge protocols allow disclosed samples and recomputed commitments to use known, measured code. Credit and capability mechanisms allow capability keys to be issued only to nodes 102 running approved, attested verification images. Synchronization and timing allow timing proofs to inherit the same code-identity guarantees.

[0222] Secure Task Execution Without Explicit Physical Verification

[0223] In some embodiments, the system can provide a secure task-execution path that gives a high probability that a task was executed as commanded, even when no explicit physical output 116 verification is performed. In these embodiments, the node 102 stillAttorney Docket No. 11855-002W01includes a secure module 104 and actuator 108, but the system omits or relaxes the requirement for sensor data 118 and physical output 116 comparison. Rather, assurance can be derived from at least one of: (i) isolation of the actuator-control logic inside a secure module 104, (ii) attested code identity for the task-execution software, (iii) cryptographic logging of actuator commands and execution results, and / or (iv) protection of the actuator interface against unauthorized control.

[0224] Actuator Control Path Inside the Secure Module. In one embodiment, the secure module 104 includes (i) a processing unit 106 that receives task assignments from the coordinator 126, (ii) actuator-control logic that converts task parameters into low-level control signals (for example, PWM waveforms, relay closures, or serial commands), and (ii) a proof engine (105) that records and signs an execution log. The secure module 104 may be wired such that only the attested processing unit 106 inside the secure module 104 can drive the actuator 108. External software or untrusted peripherals cannot directly issue actuator commands without passing through the attested control path. When the coordinator 126 assigns a task (e.g., ‘“enable output channel A at 40 % duty cycle for 2 seconds”), the processing unit 106 executes the task deterministically and records an internal execution trace, such as (i) task identifier, (ii) sequence of actuator commands issued, (iii) start and end times (or local timestamps), or (iv) internal status codes and error conditions.

[0225] Execution Attestation Without Sensor Feedback. Rather than comparing sensor data 118 to verification parameters, the proof engine (105) generates an execution attestation record that can summarize what commands were issued to the actuator 108 and whether the attested control logic reports success or failure. Table 5B shows an example structure for an execution attestation record.Table 5BExecAttest = {task_id,command_s equence_hash,start time.end_time,status_code,optional_error_flags}Proof = Sign(sk module, ExecAttest)Attorney Docket No. 11855-002W01

[0226] The coordinator 126 or verifier can check the signature and, optionally, the code attestation associated with sk module to confirm that (i) the execution report originated from an approved, measured software image running in a secure module 104 and (ii) the report has not been tampered with in transit. This can provide cryptographic assurance that the approved control software issued the correct actuator commands, even though the system does not directly measure physical output 116 for that task.

[0227] Use Cases and Tradeoffs. Secure task execution without explicit physical output verification may be used in scenarios such as: (i) purely digital tasks, where the “actuator 108” is a logical state change (for example, a database update or configuration toggle) and external measurement is unnecessary or redundant, (ii) low-risk or low-cost deployments, where the overhead of sensors and physical output 116 verification cannot be justified but tamper-resistant control is still desired, (iii) pre-calibrated or lab-verified actuators, where physical behavior has been characterized in advance and ongoing deployment focuses on protecting the command path and code identity, or (iv) hybrid systems, where some tasks use full sensor 112-based verification while others rely only on secure execution attestations.

[0228] In such embodiments, the secure task execution can still provide (i) hardware-enforced isolation of the actuator-control logic, (ii) binding between code identity7and actuator commands; and cryptographically signed execution logs, even though no sensor data 118 may be evaluated for the corresponding tasks.

[0229] Relationship to Sensor-Based Verification. The secure-execution-only mode does not replace sensor-based task verification, but rather serves as an alternative or complementary embodiment. A given node 102 or deployment may (i) use sensor-based verification for safety-critical or high-value tasks, (ii) use secure execution attestations for low-risk, digital, or auxiliary tasks; or (iii) start in secure-execution-only mode and later enable sensor-based verification as additional hardware is installed. Accordingly, the same secure module 104, processing unit 106, and proof engine (105) architecture described elsewhere can support both (i) full verification embodiments, in which sensor data 118 is compared to verification parameters and task verification proofs are generated and (ii) secure execution embodiments, in which execution attestations provide strong evidence that tasks were executed as commanded, even in the absence of physical output 116 measurements.

[0230] Actuator Control Path Inside the Secure Module. In one embodiment, the secure module 104 includes (i) a processing unit 106 that receives task assignments from the coordinator 126, (ii) actuator-control logic that converts task parameters into low-levelAttorney Docket No. 11855-002W01control signals (for example. PWM waveforms, relay closures, or serial commands), and a proof engine (105) that records and signs an execution log. The secure module 104 may be wired such that only the attested processing unit 106 inside the secure module 104 can drive the actuator 108. External software or untrusted peripherals cannot directly issue actuator commands without passing through the attested control path. When the coordinator 126 assigns a task (e.g., ‘“enable output channel A at 40 % duty cycle for 2 seconds”), the processing unit 106 executes the task deterministically and records an internal execution trace, such as (i) task identifier, (ii) sequence of actuator commands issued, (iii) start and end times (or local timestamps), and / or (iv) internal status codes and error conditions.

[0231] Execution Attestation Without Sensor Feedback. Instead of comparing sensor data 118 to verification parameters, the proof engine (105) may generate an execution attestation record that summarizes what commands were issued to the actuator 108 and whether the attested control logic reports success or failure.

[0232] Multi-observer Verification Embodiment

[0233] Figs. 8A - 8C show example observer configurations, including for multiobserver and Al-based observer. The multi-observer and Al-based observer may be employed in combination.

[0234] Figs. 8A shows a multi-observer verification configuration 800a. Several independent observer nodes 102 (shown as 802a, 802b,..., 802c) are each configured to measure the physical output 116 produced by a target node 102 (shown as 804) and generate their own task verification proofs within their respective secure modules 104. The coordinator 126 ( show n as 806) is configured to verify each proof individually and may apply quorum logic (e.g., majority agreement) to determine the final validation result. The coordinator 126 may optionally commit proof digests or aggregated outcomes to the ledger.

[0235] In Fig. 8A, a target node 804 executes an assigned task while multiple observer nodes (802a, 802b,..., 802c) independently measure the resulting physical output 116 from the target node 804. Each observer node (802a, 802b,..., 802c) includes a secure module 104 that is configured to authenticate and attest its sensor data 118. compare its respective sensor data 118 to verification parameters, and generate a task verification proof. The coordinator 806 may validate all submitted proofs and determine whether the task succeeded based on a quorum threshold, unanimity, weighted scoring, or other aggregation logic. Proof digests or aggregated decisions may optionally be submitted to the ledger for auditability or compensation.

[0236] AI-Based Observer VerificationAttorney Docket No. 11855-002W01

[0237] Fig. 8B shows an Al-based observer system 800b comprising an Al-based observer 818 executing an Al model 820. In Fig. 8B, a target node 804 produces a physical output 116 (e.g., light, movement, or acoustic pattern). An observer node 818 includes a sensor 112 and an Al inference engine 820 inside a secure module 104. The secure module 104 with the Al inference engine 820 is configured to extract semantic features, compare the semantic features to verification parameters, and generate a task verification proof signed with an attested key. The coordinator 126 can verify the proof and may optionally commit its digest to the ledger.

[0238] AI-Based Observer Verification Configuration. In certain embodiments, the system employs Al-based observers (e.g., 818) to verify physical output 116 produced by a target node (e.g.. 102, 804). The Al-based observer 818 may include at least one sensor 112 (e.g., camera, microphone, depth sensor, spectrometer, or IMU) coupled to an inference engine 820, such as a convolutional neural network (CNN), a transformer model, or another machine-learning model, executed within a secure module 104.

[0239] Fig. 8C shows an example trusted Al model execution and semantic-feature attestation. In Fig. 8C. the Al observer 818 (shown as 818a) is configured to generate semantic sensor data 118 (shown as 824) as higher-level, machine-interpreted features extracted from raw sensor measurements. Examples of semantic sensor data 824 can include and are not limited to: (i) classification of light color, pattern, or spatial distribution, (ii) recognition of human poses, gestures, or coordinated movement, (iii) detection of drone trajectories, formation shapes, or strobe patterns, (iv) identification of acoustic features such as beats, onset, timbre, or spectral energy, (v) detection of environmental changes (for example, valve states, fluid motion, or mechanical displacement), or (vi) a combination thereof.

[0240] Secure Al Inference Within the Secure Module. In one embodiment, e.g., in Fig. 8C, the raw sensor feed may remain inside a secure module 104, where an attested Al model 818a can process the data and output feature vectors, classifications, bounding boxes, or other inference results. The Al model 820 may be (i) a pre-trained and stored inside the secure module 104 or (ii) downloaded and authenticated via a signed policy list. The Al model 820 may measure and attest at initialization, similar to other code described in this specification.

[0241] The secure module 104 may bind the Al model’s identity (for example, its hash, version, or signature) to the cryptographic key used to sign task verification proofs. This can ensure that the coordinator 126 or verifier can confirm that the Al inference resultsAttorney Docket No. 11855-002W01originated from an approved, unmodified model executing within a tamper-resistant environment.

[0242] Comparison Against Verification Parameters. Examples of verification parameters for Al-based observers may specify can include and are not limited to: (i) required classifications (e.g., “pattern A must be visible”), (ii) spatial or temporal conditions (e.g., “object must move from left to right within T ms”), (iii) thresholds (e.g., “light must be predominantly hue H with confidence > 0.9”), (iv) pose or gesture constraints (e.g., “limb angles within tolerance”), (v) formation metrics for drone swarms, (vi) error bounds on detected phase, beat, or motion trajectory, or (vii) a combination thereof. The proof engine (105) may compare the Al-generated features to the verification parameters and compute a pass / fail or deviation result.

[0243] Generation ofAI-Based Verification Proofs. Examples of the task verification proof for Al-based observers (e.g., 818, 818a) can include and are not limited to: (i) the task identifier, (ii) the Al model identifier (for example, model hash or signed version), (iii) compressed or hashed semantic sensor data 118 (e.g., feature vectors, labels, or confidence scores), (iv) a pass / fail result or deviation metric, (v) a signature or zero-knowledge proof generated within the secure module 104, and / or (vi) a combination thereof. In some embodiments, the secure module 104 may also include a commitment to the raw sensor frames (for example, a Merkle root over image hashes) to enable later challenge audits without transmitting full images unless required.

[0244] In addition to the machine learning techniques described above, other artificial intelligence and machine learning techniques may be employed. The term “artificial intelligence” is defined herein to include any technique that enables one or more computing devices or comping systems (i.e., a machine) to mimic human intelligence. Artificial intelligence (Al) includes, but is not limited to, knowledge bases, machine learning, representation learning, and deep learning. The term “machine learning” is defined herein to be a subset of Al that enables a machine to acquire knowledge by extracting patterns from raw data. Machine learning techniques include, but are not limited to. logistic regression, support vector machines (SVMs), decision trees, Naive Bayes classifiers, and artificial neural networks. The term “representation learning” is defined herein to be a subset of machine learning that enables a machine to automatically discover representations needed for feature detection, prediction, or classification from raw data. Representation learning techniques include, but are not limited to, autoencoders. The term “deep learning” is defined herein to be a subset of machine learning that that enables a machine to automatically discoverAttorney Docket No. 11855-002W01representations needed for feature detection, prediction, classification, etc. using layers of processing. Deep learning techniques include, but are not limited to, artificial neural network or multilayer perceptron (MLP).

[0245] Machine learning models may include supervised, semi-supervised, and / or unsupervised learning models. In a supervised learning model, the model leams a function that maps an input (also known as feature or features) to an output (also known as target or target) during training with a labeled data set (or dataset). In an unsupervised learning model, the model leams a function that maps an input (also known as feature or features) to an output (also know n as target or target) during training with an unlabeled data set. In a semisupervised model, the model leams a function that maps an input (also known as feature or features) to an output (also known as target or target) during training with both labeled and unlabeled data.

[0246] An artificial neural network (ANN) is a computing system including a plurality of interconnected neurons (e.g., also referred to as “nodes"’). This disclosure contemplates that the nodes can be implemented using a computing device (e.g., a processing unit and memory as described herein). The nodes can be arranged in a plurality of layers such as input layer, output layer, and optionally one or more hidden layers. An ANN having hidden layers can be referred to as deep neural network or a multilayer perceptron (MLP). Each node is connected to one or more other nodes in the ANN. For example, each layer is made of a plurality of nodes, where each node is connected to all nodes in the previous layer. The nodes in a given layer are not interconnected with one another, i.e., the nodes in a given layer function independently of one another. As used herein, nodes in the input layer receive data from outside of the ANN, nodes in the hidden layer(s) modify the data between the input and output layers, and nodes in the output layer provide the results. Each node is configured to receive an input, implement an activation function (e.g., binary step, linear, sigmoid, tanH, or rectified linear unit (ReLU) function), and provide an output in accordance with the activation function. Additionally, each node is associated with a respective weight. ANNs are trained with a dataset to maximize or minimize an objective function. In some implementations, the objective function is a cost function, which is a measure of the ANN’S performance (e.g., error such as LI or L2 loss) during training, and the training algorithm tunes the node weights and / or bias to minimize the cost function. This disclosure contemplates that any algorithm that finds the maximum or minimum of the objective function can be used for training the ANN. Training algorithms for ANNs include, but are not limited to, backpropagation. It should be understood that an artificial neural network isAttorney Docket No. 11855-002W01provided only as an example machine learning model. This disclosure contemplates that the machine learning model can be any supervised learning model, semi-supervised learning model, or unsupervised learning model. Optionally, the machine learning model is a deep learning model. Machine learning models are known in the art and are therefore not described in further detail herein.

[0247] A convolutional neural network (CNN) is a type of deep neural network that has been applied, for example, to image analysis applications. Unlike a traditional neural network, each layer in a CNN has a plurality of nodes arranged in three dimensions (width, height, depth). CNNs can include different types of layers, e.g., convolutional, pooling, and fully-connected (also referred to herein as “dense"’) layers. A convolutional layer includes a set of filters and performs the bulk of the computations. A pooling layer is optionally inserted between convolutional layers to reduce the computational power and / or control overfitting (e.g., by downsampling). A fully-connected layer includes neurons, where each neuron is connected to all of the neurons in the previous layer. The layers are stacked similar to traditional neural networks. GCNNs are CNNs that have been adapted to work on structured datasets such as graphs.

[0248] A logistic regression (LR) classifier is a supervised classification model that uses the logistic function to predict the probability of a target, which can be used for classification. LR classifiers are trained with a data set (also referred to herein as a “datasef ") to maximize or minimize an objective function, for example, a measure of the LR classifier’s performance (e.g., error such as LI or L2 loss), during training. This disclosure contemplates that any algorithm that finds the minimum of the cost function can be used. LR classifiers are known in the art and are therefore not described in further detail herein.

[0249] An Naive Bayes’ (NB) classifier is a supervised classification model that is based on Bayes’ Theorem, which assumes independence among features (i.e., the presence of one feature in a class is unrelated to the presence of any other features). NB classifiers are trained with a data set by computing the conditional probability distribution of each feature given label and applying Bayes' Theorem to compute the conditional probability distribution of a label given an observation. NB classifiers are known in the art and are therefore not described in further detail herein.

[0250] A k-NN classifier is a supervised classification model that classifies new data points based on similarity measures (e.g., distance functions). k-NN classifiers are trained with a data set (also referred to herein as a “dataset”) to maximize or minimize an objective function, for example a measure of the k-NN classifier’s performance, during training. ThisAttorney Docket No. 11855-002W01disclosure contemplates that any algorithm that finds the maximum or minimum of the objective function can be used. k-NN classifiers are known in the art and are therefore not described in further detail herein.

[0251] A majority voting ensemble is a meta-classifier that combines a plurality of machine learning classifiers for classification via majority voting. In other words, the majority voting ensemble's final prediction (e.g., class label) is the one predicted most frequently by the member classification models. Majority voting ensembles are known in the art and are therefore not described in further detail herein.

[0252] Optional Multi-observer Fusion. Al observers may operate alongside traditional sensor observers in a multi-observer configuration, e.g., as that described in relation to Fig. 8A. The coordinator 126 in that configuration may (i) combine proofs from Al observers and non- Al observers, (ii) apply quorum or weighted logic, (iii) require agreement between semantic and physical measurements before declaring success, or (iv) a combination thereof. This can improve the robustness against spoofing, occlusion, or multimodal adversarial conditions.

[0253] Benefits ofAI-Based Observers. Al-based observers (e.g., 818) can enable verification of tasks that are difficult or infeasible to validate using traditional sensors alone, such as complex lighting scenes, semantic motion or gesture recognition, drone formations and spatial behaviors, texture, color, or shape-dependent tasks, and multi-agent human movement synchronization, among others. Al observers (e.g..818) can thereby extend the verification framework beyond simple numeric thresholds to semantic, high-dimensional physical phenomena, while maintaining tamper resistance through secure module 104 execution and attested model identity.

[0254] AI-Qbserver Trust Boundaries and Model-Integrity Verification

[0255] In addition to generating semantic features for verification. Al-based observers may incorporate model-integrity7, provenance, and trust-boundary mechanisms to ensure that inference results originate from a know n, unmodified, and approved model executing within a tamper-resistant environment. These mechanisms prevent adversaries from substituting altered models, injecting adversarial examples, or manipulating the inference pipeline.

[0256] In certain embodiments, Al-based observers include model-integrity and trustboundary mechanisms within a secure module 104. These mechanisms measure and attest the Al model, verily its provenance, enforce policy lists and revocation rules, seal model execution, detect adversarial manipulation, cross-check inference with multiple models or sensor modalities, and generate semantic-feature commitments subject to challenge audits.Attorney Docket No. 11855-002W01Together, these mechanisms ensure that semantic features used for task verification proofs originate from approved, unmodified Al models executing within a tamper-resistant environment.

[0257] Model Measurement and Attestation. In some embodiments, the secure module 104 is configured to measure the Al-model binary, graph representation, or machinelearning weights prior to execution. The measurement may include (i) a cryptographic hash of model parameters, (ii) a hash of neural -network architecture metadata, (iii) signatures from a model publisher or training authority, and / or optional version identifiers, provenance data, or watermark codes.

[0258] Table 5C provides an example of an attestation record. The model measurement and attestation can ensure that semantic inferences originate from a vetted model whose identity is cryptographically bound to the secure module 104.Table 5Cmodel_attest = {model hash.architecture_id,version,publisher_signature,timestamp} signed by attestation_root

[0259] Secure Loading and Model Sealing. In some embodiments, the Al model is (i) stored within sealed storage inside the secure module 104, (ii) loaded only after hashvalidation against an approved model list, (iii) decrypted internally using keys not accessible to the host system, and / or (iv) executed within a protected memory region that prevents unauthorized reads or modifications. These controls prevent model tampering or weight substitution.

[0260] Anti-Adversarial Boundaries and Input Sanitization. The secure module 104 may incorporate anti-adversarial safeguards to detect or prevent attempts to manipulate Al inference, e.g., through adversarial perturbations, structured spoofing patterns, replay of recorded sensor inputs, or synthetic data injection.

[0261] The anti-adversarial safeguards may include (i) filtering or normalizing raw sensor data before inference, (ii) using stochastic or randomized pre-processing steps, (iii) verifying monotonicity or temporal consistency of features across frames, (iv) enforcingAttorney Docket No. 11855-002W01cross-modal agreement (e.g., optical + IMU), and / or checking for discontinuities inconsistent with actuator behavior. The measures can raise the cost of Al-targeted spoofing attempts.

[0262] Model Provenance, Policy Lists, and Revocation. In some deployments, models must be approved before use. The secure module 104 may maintain (i) a policy list of allowed model hashes, (ii) model revocation lists, (iii) expiration policies requiring periodic refresh, and / or (iv) signatures from trusted authorities indicating proper training provenance If a model’s hash does not appear on the approved list, the secure module 104 may refuse to perform inference or generate task verification proofs that depend on the model.

[0263] Attested Inference Pipeline. In certain embodiments, not only the model but the entire inference pipeline can be attested by one of the following: sensor acquisition, feature extraction, model execution, post-processing of semantic features, comparison with verification parameter, or a combination thereof. Each step can operate within a measured and approved code path.

[0264] Table 5D shows an example of the attestation. The attestation can assure the verifiers that the produced semantic features were produced by a genuine pipeline running inside the secure module 104.Table 5Dsemantic_attest = {task_id,feature_summary,model_hash,inference timestamps,pass / fail,} signed by sk module

[0265] Multi-Model Cross-Checking. To further strengthen robustness, the secure module 104 may use multiple Al models: (i) different architectures (CNN + transformer), (ii) models trained on different datasets, (iii) ensemble averaging or weighted agreement, and / or (iv) multi-stage pipelines where one model validates the other’s outputs. Disagreement between models may trigger fallback to basic sensors, raise suspicion metrics, or automatically may initiate a challenge-audit as described in relation to Fig 8C.

[0266] Semantic-Feature Commitments and Challenge Audits. Similar to high-frequency sensor samples, the secure module 104 may generate commitments to semantic features or intermediate activations. Examples of semantic-feature commitments include (i) aAttorney Docket No. 11855-002W01hash-chain over per-frame feature vectors, (ii) a Merkle root over classification outputs, (iii) commitments to attention maps or feature maps, or (iv) a combination thereof.

[0267] Verifiers may later issue challenges requesting disclosure of specific frames, feature vectors, or inference metadata. This can prevent a node 102 from manipulating semantic summaries without risk of detection.

[0268] Protection Against Sensor-Model Mismatch Attacks. In certain embodiments, the secure module 104 can enforce sensor-model compatibility, preventing adversaries from feeding a model with data inconsistent with the sensor pipeline. The operation may include (i) frame-timing correlation with low-level sensor clocks, (ii) IMU cross-check for camera motion consistency, (iii) noise models tied to the physical sensor's characteristics, (iv) signalstructure checks ensuring that inputs have expected entropy, temporal smoothness, or spectral signatures, or (v) a combination thereof. The constraints can prevent fabricated or replayed inputs from being accepted as genuine.

[0269] Timing Architecture

[0270] Figs. 9A and 9B show exemplary’ system and methods in context of a timing architecture. In Fig. 9A, an example a timing architecture is shown supporting phase-aligned task execution across distributed nodes 102 (shown as 902a, 902b,..., 902c). In Fig. 9 A, nodes 102 receive a timing reference from a coordinator 126 or derives one through decentralized beacon exchange. Each node (902a, 902b,..., 902c) is configured to compute a local epoch and apply a drift correction mechanism to maintain phase alignment. Timed tasks may include both a task window 132 and a verification window’ 134. Within the secure module 104, sensor data 118 is compared to verification parameters, and each node (902a, 902b,..., 902c) is configured to generate a task verification proof (e.g., 121). Timing digests or proofs may optionally be anchored to a ledger.

[0271] In Fig. 9A, distributed nodes (902a, 902b,..., 902c) synchronize their internal clocks using either a coordinator-provided timing reference or a decentralized exchange of timing beacons. Each node (902a, 902b,..., 902c) computes a local epoch, applies drift correction, and derives the phase necessary to execute a timed physical output 116. Task assignments may specify both a task window 132 and a verification window 134, enabling precise measurement of phase alignment or temporal fidelity. During the verification window’, the secure module 104 captures sensor data 118 and compares the sensor data to expected timing bounds. Each node 102 can independently generate a task verification proof reflecting its adherence to the commanded timing, and the coordinator 126 or ledger may record these proofs or timing digests for auditability and compensation.Attorney Docket No. 11855-002W01

[0272] The timing reference may be derived from one or more secure timing sensors, including radio-frequency timing sources, celestial observations, disciplined local oscillators, environmental periodic signals, network-based timing exchanges, neighbor-based timing pulses, or combinations thereof.

[0273] Secure Timing Sources and Timing Verification Mechanisms. In various embodiments, the system includes a secure timing module 904 configured to obtain and verify timing information from one or more physical, environmental, or computational timing sources. The secure timing module 904 may be integrated within the secure module (e.g., 104 of devices 902a... 902c) or implemented as a physically separate component operating within its own tamper-resistant boundary'. Timing measurements are processed using attested code and are cryptographically bound to a device-specific identity key such that the resulting timing proofs are authenticated, tamper-evident, and verifiable by external entities.

[0274] The secure timing module 904 may incorporate radio-frequency timing sources, optical and celestial timing sources, local oscillator mechanisms, environmental timing phenomena, network-based synchronization methods, neighbor-based timing exchanges, exotic timing sources, or any combination thereof. Timing measurements may be provided as high-frequency raw samples, window-level summaries, or coarse periodic timing estimates, and may be down-sampled or aggregated in the same manner as other sensor outputs described herein.

[0275] Table 6 provides a description of example secure timing modules.Table 6Example secure Descriptiontiming moduleRadio-Frequency The secure timing module 904 can receive timing information from Timing Sources Global Navigation Satellite System (GNSS) constellations such as GPS, Galileo, GLONASS, BeiDou, or other satellite or orbital systems. A GNSS RF front-end may be located outside the secure module 104, while signal correlation, code tracking, decoding, and timing extraction occur inside the secure module 904 or a tamperresistant timing boundary'. Timing estimates may include satellite identifiers, code-phase values, Doppler shifts, oscillator bias, timing uncertainty’, and associated quality metrics. Additional embodiments may utilize timing information derived from otherAtorney Docket No. 11855-002W01satellite downlinks, including but not limited to communication satellites and meteorological satellites whose downlink framing includes a periodic or deterministic timing structure.Terrestrial radio timing sources may also be used, such as WWVB, DCF77, MSF, JJY, CHU, or amateur radio time beacons. Further embodiments may derive timing from ultra-wideband (UWB) anchors, cellular systems (for example, 4G or 5G synchronization signals), WiFi access points (for example, using 802.11 timing synchronization function (TSF) timestamps), or Bluetooth Low- Energy (BLE) periodic advertising events.Optical and Celestial The secure timing module 904 can derive timing information from Timing Sources celestial observations, treating celestial bodies as natural timing beacons. The secure module 104 may expose a small optical aperture coupled to internal optics and an image sensor or photodiode array, with all optical detection, image capture, feature extraction, and timing calculations occurring within the secure boundary. Examples can include but are not limited to (i) solar timing, using a measured Sun vector and an internal solar ephemeris, (ii) stellar timing, using star-field identification and an internal star catalog to derive sidereal time, (iii) lunar timing, based on Moon position or phase, (iv) planetary timing, using planets with predictable ephemerides, or (v) twilight timing, using the rate of change of sky brightness to estimate sunrise or sunset transitions. Timing proofs may include celestial object identifiers, estimated time ranges, orientation estimates, fiting errors, sky brightness, or other quality metrics.Local Oscillators The secure timing module 904 may include a local oscillator, such and Disciplined as a temperature-compensated crystal oscillator (TCXO), oven- Clocks controlled crystal oscillator (OCXO), microelectromechanical (MEMS) resonator, or miniature atomic clock. Timing from the local oscillator may be used alone or in combination with external timing sources. The secure module 104 may store oscillator calibration data, drift models, temperature coefficients, andAtorney Docket No. 11855-002W01correction factors, and may apply external timing measurements to discipline the oscillator and generate a stable, authenticated monotonic timebase. The secure module 904 may generate signed timing proofs reporting oscillator frequency, drift estimates, applied corrections, variance measurements, or monotonic tick counters, which can be used by verifiers to reconstruct or validate a node’s internal notion of time.Additional embodiments may include rubidium or other macroscopic atomic clocks, GPS-disciplined or GNSS-disciplined oscillators (GPSDO / GNSSDO), dual-oscillator holdover architectures, laser-stabilized or optical resonator clocks, or other high-stability or low-noise timing references.Environmental In certain embodiments, timing may be derived from environmental Timing Sources periodic signals, including but not limited to (i) power-line frequency and zero-crossings (for example, 50 Hz or 60 Hz grids), (ii) mains hum observable acoustically or electromagnetically, (iii) building vibrational modes, (iv) periodic machinery7or HVAC cycles, or (v) a combination thereof. These sources can provide coarse timing and may be used alone or as cross-checks against other timing mechanisms.Network-Based Timing information may be derived from network timestamps, Timing including NTP, SNTP, PTP, or similar network-based protocols.Timing values may be collected over wired or wireless links.Network timing need not be trusted directly; instead, the secure module 104 may use such values as supplementary' or relative timing anchors, may combine them with authenticated local oscillator data, or may include them as inputs to timing quality7assessments. Additionally, timing may be inferred from timestamps derived from distributed or decentralized systems, including blockchain consensus (for example, block-time windows), which provide coarse, globally verifiable time boundaries.Attorney Docket No. 11855-002W01Neighbor-Based Nodes (e.g., 904) may exchange timing pulses or timestamps Timing Exchanges directly to achieve relative or consensus timing. Examples can include but are not limited to: (i) optical timing pulses between neighboring nodes, (ii) UWB round-trip timing exchanges, (iii) radio timestamp broadcasts, (iv) beat-synchronization messages, and (v) phase-alignment protocols.Nodes 102 may execute distributed or Byzantine-resilient algorithms to derive consensus time or to verify timing consistency across nodes. In such embodiments, anode’s timing proofs may include information about neighbor-derived offsets, convergence metrics, or consensus confidence.Exotic and High- Embodiments may include timing derived from rare or Entropy Timing unconventional phenomena, such as cosmic-ray arrival events, Sources solar flare detection, astronomical transients, or deep-space radio bursts. These sources typically provide coarse timing but may serve as independent verification of timing integrity or as high-entropy timing anchors.

[0276] Timing Proof Generation and Verification. In all embodiments, timing measurements are processed within attested code running on the secure module 904. A timing proof may include one or more of: local time; external timing sources used, raw measurement data or summaries, oscillator state; drift estimates, quality or confidence metrics, measurement counters, task epoch identifiers, code hash of the timing software, and secure module 904 identity. The timing proof may be signed using a private key bound to the secure module 904 via hardware attestation or stored in secure memory.

[0277] Verifiers may inspect the timing proof, evaluate quality metrics, compare multiple timing sources, and incorporate timing into higher-level verification or coordination processes, including the timing flows illustrated in Fig. 9A. Timing proofs or timing digests may also be recorded on a ledger or other append-only log for auditability and dispute resolution.

[0278] In some embodiments, the timing subsystem itself can execute within a secure module or trusted execution environment, such that clock discipline, epoch selection, driftAttorney Docket No. 11855-002W01estimation, and timing-proof generation are performed by attested code. In the embodiments, timing outputs, oscillator adjustments, and derived time values may be cryptographically bound to the measured software image and the secure module’s identity key, thereby providing verifiable provenance and tamper-resistant timing for use in task and verification windows.

[0279] Wireless Throughput. Channel Utilization, and Spectrum-Sharing Benefits of Time Synchronization. In many embodiments, the timing architecture can provide not only alignment for task execution and verification, but also measurable improvements to wireless spectrum efficiency. When nodes (e.g., 902) share a common timing reference (e.g., derived from GNSS, UWB ranging, BLE periodic advertising, network-based timestamps, or decentralized neighbor consensus), the system may coordinate radio transmission opportunities among nodes 102 with substantially reduced contention, collisions, and retransmission overhead.

[0280] In one embodiment, nodes 902 may employ sy nchronized transmission windows or time-division multiple access (TDMA) epochs, derived directly from the shared epoch computed by the secure timing module 904. Each node 902 may broadcast sensor summaries, task proofs, timing proofs, or mesh-synchronization packets only during its assigned micro-window. This can reduce medium access contention, minimize packet collisions, and increase effective system-wide throughput without requiring a centralized scheduling authority. The shared epoch enables deterministic scheduling even in deployments that lack persistent connectivity to the coordinator 126 or the ledger.

[0281] In another embodiment, nodes 902 use the synchronized epoch to establish phase-shifted beaconing patterns. By offsetting UWB, BLE, or Wi-Fi management frames according to timing phase, nodes 102 reduce the probability of simultaneous transmissions. This technique improves airtime availability and reduces channel occupancy, allowing dense clusters of nodes 102 — such as lighting installations, drone swarms, or sensor arrays — to share limited spectrum more efficiently. Coordinators or distributed algorithms may reassign phase offsets dynamically based on local congestion, node 102 density, or credit-based prioritization.

[0282] In a further embodiment, nodes 902 can leverage fine-grained timing to implement listen-before-talk (LBT) operations with predictable backoff intervals. Because each node’s backoff schedule may be anchored to the shared epoch, their randomization windows do not overlap arbitrarily, reducing contention. Alternatively, nodes 902 may useAttorney Docket No. 11855-002W01frequency hopping or channel hopping sequences derived from the shared timing reference, enabling distributed frequency diversity while maintaining synchronized proof windows.

[0283] Overall, by enabling coordinated wireless timing, the system can improve aggregate network throughput, spectrum-sharing efficiency, collision avoidance, latency for proof submission, and battery7efficiency (less idle listening and fewer retransmissions). The wireless-level improvements can directly enhance the scalability of the Task Verification framework in dense or high-traffic deployments.

[0284] Timing Modes and Ranges of Timing Tightness. In different deployments, the system may operate under distinct timing regimes, each of which is supported by the same task verification mechanisms. Examples of different timing regimes can include and are not limited to: global time mode, relative phase alignment mode, coarse or asynchronous timing mode.

[0285] Global Time Mode. In a global time mode, nodes 902 can share a common absolute or quasi-absolute timebase, such as GNSS-derived time, disciplined oscillator time, or time inferred from a consensus system (for example, blockchain block intervals). Task assignments in this mode may specify: (i) absolute start and end times for the task window 132 and verification window 134, maximum permitted skew between the node’s local time and the timing reference, and tight phase or latency bounds.

[0286] Verification in this mode may include checking that the task verification proof is accompanied by a timing proof indicating that the node’s local clock was within a defined error bound (for example, ±1 ms) of the reference during execution. This can enable high-precision, phase-aligned behaviors such as synchronized lighting patterns, drone swarms, or beat-synchronous audio-reactive installations.

[0287] Relative Phase Alignment Mode. In a relative phase alignment mode, nodes 102 may not share a meaningful absolute clock, but they derive a common epoch or phase marker from timing beacons, leader broadcasts, or neighbor exchanges. The system then defines task windows and verification windows relative to this epoch or phase, e.g., “execute this pattern at beat index k,” “strobe every T milliseconds with phase offset ip,” or “align to the next N pulses from a timing leader.” Verification in this mode focuses on whether the Node’s physical output 116 and sensor data 118 are aligned in phase or relative timing with respect to the shared epoch, rather than with respect to an external wall-clock. Timing proofs may report phase error, beat index, or frame alignment error, and the proof engine (105) can evaluate whether these fall within assigned tolerances.Attorney Docket No. 11855-002W01

[0288] Coarse or Asynchronous Timing Mode. In a coarse or asynchronous timing mode, nodes 902 may not share any precise timing reference at all. Instead, the system constrains behavior using: (i) minimum and maximum allowed delays between observable events (for example, “output must follow trigger within 2 seconds”), (ii) causal ordering (for example, “event B must occur after event A and before event C”), or (iii) broad time ranges (for example, “any completion before a deadline is acceptable”).

[0289] In such embodiments, the task window 132 and verification window 134 may be expressed in terms of: (i) local timestamps measured by the Node’s own clock, (ii) sequence numbers or counters, or (iii) externally observable triggers (for example, “receipt of a signed command” or “detection of a specific pattern”). The proof engine (105) may still generate a task verification proof that includes timing-related metadata (e.g., local timestamps, counters, or measured delays), and the coordinator 126 or verifier can evaluate whether these satisfy the coarse constraints. For example, the verifier may check that (i) the measured delay between a signed trigger and the reported actuation is less than a maximum bound, (ii) the ordering of signed events is consistent across multiple nodes 902; or (iii) sensor data 118 indicates that an output was produced before a deadline, even if absolute time is not known.

[0290] Integration With Task and Verification Windows. Across all modes, the task windows and verification windows can provide a generalized abstraction for “when” a task should happen and “when” it should be measured. In high-precision deployments, these windows may be tightly specified and aligned with a global reference; in lower-precision or connectivity-limited deployments, the same windows may be defined relative to local events or coarse deadlines. Accordingly, the system does not require a globally shared timebase to perform task assignment and verification. Instead, it supports a range of timing tightness, from sub-milhsecond, globally referenced synchronization to coarse, event-ordered verification, while using the same secure module 104, sensor data 118, and proof engine (105) architecture described elsewhere in this specification.

[0291] Resource monitoring Implementation (124). Nodes (e.g., 102, 902) may monitor energy consumption, bandw idth, or other metrics and cryptographically validate the data. As an example, e.g., for, energy monitoring, the resource monitoring (e.g., 124) may be used with a node (e.g., 102, etc.) controlling an electric load that measures power draw7every 100 ms using a calibrated shunt sensor. The secure module 104 computes an average of 46.2 W over 10 samples against an assigned limit of 50 W. The proof engine (105) signs the tuple {task_id, average = 46.2, limit = 50, pass = true} and transmits it to the coordinator 126. TheAttorney Docket No. 11855-002W01coordinator 126 validates the signature and records the reading locally or on the ledger. This embodiment illustrates how the same verification principle applies to non-optical resources such as energy, bandwidth, or mechanical work.

[0292] Blockchain Integration & Value Exchange. Proofs and resource data may be submitted to a blockchain to enable transparent validation and fair compensation. Alternative designs may use append-only logs, distributed hash tables, or authenticated local storage for deployments where blockchain connectivity is intermittent or unnecessary. The ledger interface is optional. Systems without blockchain may record proofs locally or via authenticated logs; the invention remains applicable regardless of ledger presence. Upon validation, a smart contract or off-chain agent releases payment to the node. The compensation loop can incentivize the truthful verification without requiring trusted intermediaries.

[0293] In some embodiments, the system can connect to a blockchain or other cryptographically authenticated distributed network to enable cryptoeconomic incentives, including the issuance, transfer, or settlement of rewards, penalties, or capability keys tied to verified task execution. The distributed network may include Ethereum-based systems (e.g.. Layer- 1, Layer-2, or Layer-3 chains), non-EVM blockchains, D AG-based consensus networks, proof-of-stake or proof-of-history chains, or any execution environment capable of maintaining authenticated state. In such embodiments, a node or coordinator may submit task verification proofs, timing digests, resource-usage summaries, or credit-state updates to the distributed network, while also retrieving block timestamps, state roots, or smart-contract outputs. These interactions allow the system to use external blockchain networks as trust anchors for decentralized verification, settlement, and cryptoeconomic coordination.

[0294] Example Ledger Configuration and Trustless Record-Keeping Structures

[0295] In certain embodiments, the ledger (e.g., 128) may include any cryptographically authenticated append-only structure capable of storing task records, proofs, timing digests, or credit-state transitions. The ledger may be implemented as a blockchain, replicated log, authenticated data structure, distributed hash table, CRDT-based store, or secure local log with periodic commitments. These designs allow the system to operate in environments with varying degrees of decentralization, connectivity, trust assumptions, and performance requirements, while retaining tamper-evident verification of task execution.

[0296] In various embodiments, the system may employ generalized trustless or authenticated record-keeping mechanisms that extend beyond traditional blockchain systems. The mechanisms can ensure that task verification proofs, timing digests, resource-usageAttorney Docket No. 11855-002W01summaries, credit updates, and state transitions remain tamper-evident even in environments lacking continuous connectivity or global consensus. The ledger may therefore be implemented using one or more of the following structures, each providing different performance, availability. and decentralization tradeoffs.

[0297] Fig. 9B - 9F each show an example ledger configuration that may be employed with the system and method described herein. In Figs. 9B - 9F, the ledger 128 can be blockchains 950a. replicated logs 950b, authenticated data structures 950c, DHT-based storage 950d, CRDTs, or secure local logs 950e with periodic commitments. Each architecture provides tamper-evident record-keeping and verification through signatures and hash-chaining, enabling deployment across centralized, decentralized, or intermittently connected environments.

[0298] Table 7 provides examples of ledger and trustless record-keeping structures.Table 7Example ledger and Descriptiontrustless recordkeeping structuresReplicated Append- The ledger may be implemented as a replicated append-only log Only Logs (950b) maintained by a cluster of nodes 102. Each entry may be (i)cryptographically signed, (ii) hash-chained to the previous entry, and / or (iii) replicated across multiple peers. The replicated append-only log can provide strong tamper evidence without requiring global consensus or a full blockchain. Nodes 102 may replay or audit the log to reconstruct proof histories, credit states, or timing events.Authenticated Data The ledger 128 may include an authenticated data structure such as Structures (950c) a Merkle tree, Merkle Patricia trees, Accumulator trees, or vector commitments. Nodes (e.g., 102) may commit to a root hash and provide Merkle proofs or accumulator proofs to authenticate task verification proofs or resource data. This enables compact verification without requiring storage of the full dataset.Distributed Hash Nodes 102 may participate in a distributed hash table, storing Tables (DHTs) signed records or proof fragments across multiple peers. Each (950d) record may be (i) keyed by hash(task_id proof_digest) and (ii)Attorney Docket No. 11855-002W01replicated according to the DHL’s routing or redundancy policies. DHT-based storage can allow decentralized access and retrieval without a centralized coordinator or blockchain, while signatures preserve integrity.Conflict-Free For deployments requiring offline operation followed by later Replicated Data reconciliation, the ledger may be implemented using CRDTs.Types (CRDTs) Nodes (e.g., 102) may maintain (i) local logs of signed proofs (95 Oe) and / or (ii) CRDT state objects representing credit scores, timing metadata, or aggregated summaries. CRDT merge semantics can ensure that independent updates converge deterministically, while signatures ensure the authenticity of each contribution.Local Secure Logs Nodes (e.g., 102) may maintain a ledger-like entry in a local (950f) database / logs. The logs may be a set of signed entries.

[0299] Local Authenticated Storage with Periodic Anchoring. Each node (e.g.. 102) can maintain a local secure log inside the secure module 104 or sealed storage. Periodically, the node 102 can (i) compute a commitment (hash, Merkle root, or accumulator digest) over recent entries, (ii) transmit the commitment to peers, a coordinator 126, or an external system, and / or (iii) optionally, anchor the commitment to a blockchain or other append-only service. This feature can provide tamper-evident local history even if the full log never leaves the node 102.

[0300] Multi-Tier Ledger Architectures. The ledger may be organized into multiple tiers. Example of tiers may include (i) Tier 1: local secure logs stored inside each secure module 104, (ii) Tier 2: regional or cluster-level authenticated logs or DHT storage, and (iii) Tier 3: optional global blockchain anchoring for long-term auditability. The hierarchical architecture can permit scalable storage and verification across large distributed systems.

[0301] Event-Driven or Epoch-Driven Ledger Updates. Instead of continuous commits, ledger records may be appended based on task epochs, timing epochs, periodic windows, credit-score changes, or challenge-audit results. This can reduce traffic and enable batch verification of task verification proofs or aggregated summaries.

[0302] Decentralized, Coordinator-Free, and Ledger-Free Embodiments

[0303] In some embodiments, the system operates without a dedicated coordinator 126 and without a shared ledger 128, while still providing tamper-resistant verification ofAttorney Docket No. 11855-002W01task execution. In all decentralized embodiments, the verification and secure module mechanisms remain unchanged: (i) tasks are assigned using authenticated commands, (ii) secure modules 104 can execute tasks, measure physical output 116 (or secure execution) and generate task verification proofs, (iii) proof engines (105) operate within tamper-resistant boundaries; and (iv) verification is performed using cryptographic checks on proofs and, where applicable, on timing and sensor data 118. The difference lies in how coordination and record-keeping are distributed. Instead of a single coordinator 126 and global ledger 128, coordination responsibility and log storage are spread across the nodes 102 themselves, allowing the system to operate in fully decentralized, coordinator-free, or ledger-free environments while retaining verifiable task execution.

[0304] Table 8 shows examples and descriptions of decentralized embodiments.Table 8Decentralized DescriptionNodeFeaturesPeer-to-Peer Nodes 102 can assign tasks directly to one another using authenticated Task channels based on their node identity / cryptographic Identity keys. A Assignment sending node can sign each task assignment, including task parameters, expected bounds, and optional timing metadata. The receiving node can execute the task within its secure module and return a task verification proof to the sender or to a small set of peers.Distributed Rather than relying on a single coordinator 126, multiple nodes 102 Proof independently verify’ task verification proofs. A node 102 may (i) verify Verification proofs only for tasks it assigned, (ii) exchange proofs with neighboring nodes 102 for redundancy, or (iii) participate in a consensus or quorum protocol where a proof is accepted only if a threshold number of nodes 102 agree on its validity.Local and In ledger-free embodiments, each node 102 maintains a local append-only Peer- log of tasks, sensor data 118 summaries, and task verification proofs. Replicated Logs may be (i) stored entirely within the secure module 104 or sealed Logs storage, (ii) replicated opportunistically to neighboring nodes 102, (iii) periodically exported to an external archival system when available. EachAttorney Docket No. 11855-002W01log entry- may be signed by the node’s identity key, providing tamper- evident history without requiring a global ledger.Gossip and Nodes may exchange signed summaries of their local logs, such as counts Summary of successful and failed tasks, credit or reputation scores, timing or Exchange synchronization quality metrics, commitment hashes over recent task verification proofs. These summaries allow nodes (e.g., 102) to assess one another’s behavior and creditworthiness without a centralized coordinator 126 or blockchain.Threshold and A task may be considered verified if (i) a threshold number of Quorum independent nodes 102 (e g., observer nodes 102 as in the multi-observer Mechanisms embodiment) produce agreeing task verification proofs or (ii) a threshold number of nodes 102 agree on the validity of a proof produced by a target node 102. Threshold verification can be implemented using simple majority voting, weighted quorum rules, or more advanced Byzantine- resilient consensus protocols.Offline and The system may- remain functional in environments where connectivity to Intermittent any coordinator 126 or ledger is intermittent or unavailable. Nodes (e.g., Connectivity- 102) may (i) execute and verify tasks using only local secure module 104s Modes and resource monitors 124, (ii) issue task verification proofs and store them locally, and / or (iii) reconcile logs and credit scores later when peer connectivity- or optional ledger connectivity is restored.Direct Value Value exchange may be performed without a globally shared blockchain. Exchange For example, (i) nodes (e.g., 102) may settle payments off-chain using Without a bilateral channels or vouchers derived from capability keys, (ii) a local Global Ledger operator may periodically review signed logs and compensate nodes (e.g.,102) according to locally defined policies, or (iii) nodes 102 may use hardware tokens or short-lived capability keys as “permission tickets” that embody economic value but do not require immediate on-chain settlement.

[0305] Coordinator-Free Peer Verification (ledger-Free Embodiment). Figs. 10A and 10B each show an example operation of the coordinator-free, ledger-free embodiment 1000a, 1000b, respectively. In Fig. 10A and 10B, distributed nodes (e.g., 102) are shownAttorney Docket No. 11855-002W01configured to assign tasks, as well as (i) execute them within their secure module 104s, (ii) generate task verification proofs, and (iii) verify each other's proofs directly. Local append-only logs are maintained within each node 102, and optional peer nodes 102 may independently verify or acknowledge proofs. No centralized coordinator 126 or global ledger is required; all coordination and verification functions are distributed among the nodes 102.

[0306] In the example shown in Figs. 10A and 10B. a node 102 (shown as 1002a) is configured to assign (1004) a task to another node 102 (shown as 1002b). Node 1002b, via its secure module 104, executes the task (1006a), measures the physical output (1006b), and verifies the measurement to generate a proof (1006c). The proof is provided (1008) from the verifying node 1002b back to the assigning node 1002a, which forwards (1110) a task_proof to a proofing node 1002c configured to verify (1012) the proof.

[0307] In Fig. 10B, the nodes may forward (1114) tasks and proofs to additional peers for independent verification.

[0308] Example Sensor Modalities

[0309] Sensor Modalities. Fig. HA shows examples of sensory modalities 1100a that may be used with the verification controller 111 of the system and methods described herein. The verification architecture described herein applies to a wide range of physical sensing modalities. In different embodiments, the resource monitor 124 and secure module 104 may incorporate one or more of the following sensor families, each enabling task verification proofs for domain-specific actuators and outputs. All modalities operate within the same framework of authenticated sensor data 118, comparison against verification parameters, and cryptographic proof generation within a tamper-resistant secure module 104.

[0310] In Fig. 11A, the example sensor modalities can include thermal (1102), RF (1104). lidar (1106), acoustic (1108), environmental (1110), chemical (1112), electrical (1114) (e.g., capacitive), magnetic (1116), optical (1118), and inertial sensors (1120), any of which may be integrated into the secure module 104 or resource monitor 124 for generating authenticated sensor data 118 used in task verification proofs.

[0311] Table 9 provides a description of the various example sensor modalities.Table 9Example sensor DescriptionmodalityThermal and Infrared The system can measure thermal signatures or infrared emissions Sensing (1102) generated by an actuator. The secure module 104 may incorporate:Atorney Docket No. 11855-002W01thermopiles or microbolometers, RTDs or thermistors, infrared photodiodes or spectral IR sensors, or sealed thermal conduction paths linking actuator and sensor. Verification parameters may specify expected heat profiles, rise-time curves, or IR spectral bands. Proofs confirm that measured heat output matches commanded actuator power, duration, or patern.Radio-Frequency The resource monitor 124 may include RF or radar sensors to (RF), Radar, and measure motion, presence, or emited signals from an actuator. Time-of-Flight (ToF) Examples can include FMCW radar for motion or position Sensing (1104) validation, UWB ToF or TDoA receivers for timing and distance verification, RF power detectors confirming emissions from RF actuators, and / or Doppler radar verifying mechanical movement or rotation. Sensor data 118 may include phase, amplitude, return profiles, or timing measurements; these are compared to verification parameters and incorporated into task verification proofs.Lidar, Structured- The secure module 104 may integrate lidar receivers (ToF or Light, and Depth amplitude-modulated), structured-light depth sensors, stereo or Sensing (1106) multi-baseline depth cameras, and / or single-photon avalanche diodes (SPADs). The sensors can measure 3-D structure, position, volume, or motion of physical outputs. Verification may include depth changes, surface reflectance, distance profiles, or geometric alignment with commanded trajectories.Acoustic, Ultrasonic, For tasks involving sound, movement, or pressure waves, the and Vibrational secure module 104 may include microphones or microphone Sensing (1108) arrays, ultrasonic transducers or echo sensors, vibration pickups, piezo discs, or accelerometers, and / or matched acoustic filters or resonant cavities. Verification parameters may specify waveform envelopes, frequency content, timing alignment, sound-pressure thresholds, or echo-return profiles.Environmental and The resource monitor 124 can measure environmental effects of an Atmospheric Sensing actuator, including: humidity or vapor changes (humidifiers, (1110) atomizers), air-quality metrics (gas sensors, VOC detectors),Attorney Docket No. 11855-002W01particulate detection (PM2.5, PM10), and / or barometric or micropressure changes. Proofs can confirm that environmental changes follow expected trends for a commanded physical action.Chemical, Fluidic, The system may verify tasks involving chemical reactions, fluid and Electrochemical flow, or electrochemical output using sensors such as: pH or ion- Sensing (1112) selective electrodes, electrochemical gas sensors, microfluidic flow sensors (thermal, optical, or Coriolis-based), and / or pressure or differential-pressure sensors for liquid or gas systems.Verification parameters may include concentration thresholds, flow-rate windows, reaction timing, or pressure curves.Capacitive, Inductive, In embodiments where actuators modify electrical properties, the and Resistive Sensing secure module 104 may incorporate: capacitive proximity or (1114) displacement sensors, inductive sensors detecting metallic movement, resistive strain gauges, and / or impedance sensors measuring fluid levels or mechanical load. Measurements are authenticated and compared to the expected electrical signatures of the commanded actuation.Magnetic and Hall- Magnetic sensors may verify motion, rotation, or field strengths Effect Sensing (1116) associated with actuators.Optical (1118) Optical sensors are mainly a non-contact sensing technology that detects variations in light energy' and produces a resultant electrical signal or change in conductivity based on the photoelectric or photoconductive effect, respectively.Inertial sensors Inertial sensors, often combined in an Inertial Measurement Unit (1120) (IMU), are devices that use a combination of an accelerometer (to measure linear acceleration) and a gyroscope (to measure rotational velocity) to sense motion. They work by measuring the forces and rotations acting on them to determine changes in an object's position, velocity, and orientation without relying on external references.

[0312] Other embodiments may employ RF radar or mmWave sensors, UWB or RF time-of-flight sensors, thermal imaging arrays, mechanical force or pressure sensors, tactileAttorney Docket No. 11855-002W01or touch sensors, proximity sensors, biosensors, or vision-based cameras (including RGB and event cameras), any of which may be used individually or in combination to verify physical outputs or human-actuated events.

[0313] Fig. 1 IB shows an example operation for one example sensor modality.Indeed, these non-limiting examples demonstrate that the same task-verification loop comprising assignment, secure execution, measurement, comparison, proof generation, and optional ledger recording can be applied broadly to both physical and computational tasks. Fig. 1 IB shows the example in the context of a lighting system.

[0314] Fluid-control systems may employ valves or pumps to act as actuators, while flow or pressure sensors serve as resource monitors 124. The secure module 104 can validate that measured flow rates remain within commanded limits and sign an attestation for the coordinator 126. Energy or smart-metering networks may have nodes (e.g., 102) equipped wi th current or voltage sensors that report energy usage or delivery performance. Proofs may confirm that consumption or production stays within scheduled or contractually specified bounds. Robotics and servo systems may employ motor controllers to execute position or torque commands, while encoders or load sensors supply measurements. The proof engine (105) may verify motion accuracy and generate signed proofs of compliance. Environmental monitoring may employ sensors for temperature, humidity, or air quality validating that readings conform to expected ranges after calibration tasks. Software-only verification can employ, in purely digital contexts, a secure module 104 implemented in a trusted execution environment or container that executes a deterministic computation and produces a zeroknowledge proof of correct output.

[0315] The verification system can be adapted for a variety of physical and digital domains beyond lighting and drone synchronization, e.g., fluid control systems, energy or smart metering, robotics and servo systems, environmental monitoring, and software-only verification, among others.

[0316] Example Cryptoeconomic Incentive and Operations

[0317] Figs. 12A - 12D show a value exchange mechanism that may be implemented using the system and method described herein. A value exchange mechanism is a component or logic that enables the distribution of rewards, payments, or credits for verified task execution.

[0318] Fig. 12A shows an incentive and capability-key architecture. In an embodiment, nodes can generate task verification proofs that are evaluated by a coordinator 126 or a verifying entity. Based on the outcome of verification, the system can update a creditAttorney Docket No. 11855-002W01state associated with each Node and issue or revoke a corresponding capability key. The capability’ key may govern participation in subsequent tasks or access to system functions. Verified tasks may also trigger economic rewards or payments, and credit or payment events may optionally be recorded on a Ledger or other authenticated record-keeping structure. This architecture enables trust calibration, access control, and incentive alignment based on verifiable task execution.

[0319] In Fig. 12A, the operation 1200a is shown for nodes 102 (shown as 1202a, 1202b) that operate with a coordinator 126 (shown as 1204). The nodes 1202a, 1202b each perform a task verification proof 121, e.g., as described in relation to Figs. 7A - 7C, and provide the respective proofs to the coordinator 1204. The coordinator 1204 verifies (1206) the proofs, to perform (i) an authorized payment or reward operation (1208a), (ii) an update credit state operation (1208b), and / or (iii) issue or revoke a capability key (1208c).Operations 1208b, 1208c can provide an update to the capability key 1210 or credit state 1212 for the respective node (1202a, 1202b).

[0320] Fig. 12B shows a verification-driven incentive flow. In this embodiment, a task verification proof produced by a node 102 is evaluated and may be subject to audit or additional consistency checks. The audit result is used to adjust the node’s credit state, which in turn can influence the issuance or revocation of a capability key. The verification outcome may also determine whether the Node receives a reward or incurs a penalty. Credit updates or payment events may optionally be anchored to a ledger 128 or other authenticated log. The operation shows that verification outcomes can drive economic and operational consequences within the system.

[0321] In Fig. 12B, the verification-driven incentive flow 1200b is shown, where the task verification operation 1220 includes a task verification proof 121 that is used to generate an audit result 1222. The audit result 1222 is used to provide a credit update (1224), which can issue or revoke a capability key (1226), to generate a reward or penalty (1228). The updates may be recorded on the ledger (optional).

[0322] Fig. 12C shows a capability-key lifecycle. In the embodiment, a coordinator 126 or verifying entity evaluates anode’s credit state and issues a capability key enabling the node 102 to participate in tasks or system functions. The capability' key may be exercised during normal operation, and subsequent verification outcomes may trigger revocation or renewal of the key. The lifecycle may include issuance, active use, revocation, and reissuance based on the node’s observed behavior and credit history. The embodiment showsAttorney Docket No. 11855-002W01that capability keys can enable dynamic access control in response to verifiable task execution.

[0323] In Fig. 12C, the coordinator 126 or verifier is shown configured to perform an evaluation (1230) of a credit state to (i) issue a capability key (1232a), (ii) revoke a capability key (1232b), or (iii) renew capability' key (1232c), to provide (1234) to a secure module 104 of a node (e.g., 102, 1202). The node (e.g., 1202) can participate (1236) in a task to provide an update (1238) to the coordinator 126 or verifier.

[0324] Fig. 12D shows credit-state evolution. In the embodiment, a node 102 can maintain a credit state that reflects its historical verification performance. Accepted task verification proofs can cause the credit state to increase, while failed verification or audit events cause the credit state to decrease. If the credit state reaches a predefined threshold, the system may apply a slashing or penalty action. The credit state may be updated incrementally over time and may optionally be recorded on a Ledger or other authenticated data structure. The operation shows that the system can maintain a trust or reputation signal that adapts to a node behavior.

[0325] In Fig. 12D, the credit state 1211 of the node (e.g.. 1202), e.g., as maintained by the secure module 104, can be increased (1242), decreased (1244), or slashed (1246) by the coordinator 126 or verifier based on an accepted verification (1248) or failed verification (1250).

[0326] Fast Verification. There is a mode in which fast generation of proofs at the secure sensor package is desired but the verification of the proofs can be performed more slowly. To accommodate such fast generation of proof, the system can perform verification in batches. Verification can lag proof generation in applications where the system can tolerate some period of misbehavior of actuators or misbehaving sensors. Offending nodes may be penalized by lowered credit. The credits may behave as cryptographic keys owned or controlled by the nodes of the system and used to authorize actions.

[0327] Conclusion

[0328] As used in the specification and the appended claims, the singular forms “a,” "an" and "the" include plural referents unless the context clearly dictates otherwise. Ranges may be expressed herein as from “about” one particular value, and / or to “about” another particular value. When such a range is expressed, another implementation includes from the one particular value and / or to the other particular value. Similarly, when values are expressed as approximations, by use of the antecedent "about,” it will be understood that the particular value forms another implementation. It will be further understood that theAttorney Docket No. 11855-002W01endpoints of each of the ranges are significant both in relation to the other endpoint and independently of the other endpoint.

[0329] " Optional" or “optionally” means that the subsequently described event or circumstance may or may not occur and that the description includes instances where said event or circumstance occurs and instances where it does not.

[0330] Throughout the description and claims of this specification, the word “comprise” and variations of the word, such as “comprising” and “comprises,” means “including but not limited to,” and is not intended to exclude, for example, other additives, components, integers or steps. “Exemplary” means “an example of’ and is not intended to convey an indication of a preferred or ideal implementation. “Such as” is not used in a restrictive sense but for explanatory purposes.

[0331] Disclosed are components that can be used to perform the disclosed methods and systems. These and other components are disclosed herein, and it is understood that when combinations, subsets, interactions, groups, etc. of these components are disclosed while specific reference of each various individual and collective combinations and permutation of these may not be explicitly disclosed, each is specifically contemplated and described herein, for all methods and systems. This applies to all aspects of this application, including, but not limited to, steps in disclosed methods. Thus, if there are a variety of additional steps that can be performed it is understood that each of these additional steps can be performed with any specific implementation or combination of implementations of the disclosed methods.

[0332] The following patents, applications, and publications, as listed below and throughout this document, are hereby incorporated by reference in their entirety herein.

Claims

1. Attorney Docket No. 11855-002W012.What is claimed is:

1. A system for verifying task execution in a distributed or centralized network, comprising:4.a coordinator configured to assign a task having parameters and expected bounds to one or more nodes;5.at least one node comprising (i) a secure module configured to execute the task and (ii) a resource monitor that measures a resulting output, wherein the secure module comprises a proof engine configured to compare the measured output with the expected bounds and generate a cryptographic proof of correctness; and6.a verification mechanism within the coordinator that receives and validates the cryptographic proof.

2. The system of claim 1, wherein the secure module comprises a Trusted Execution Environment (TEE) or secure enclave that, isolates task execution and proof generation from external tampering.

3. The system of claim 1 or 2, wherein the cryptographic proof comprises a zero¬ knowledge proof that validates task correctness without revealing task data.

4. The system of any one of claims 1-3, wherein the resource monitor comprises one or more physical sensors that measure fight intensity, power consumption, motion, or env i ronmental con ditions.

5. The system of any one of claims 1-4, wherein the ledger comprises a blockchain that immutably records task identifiers, proofs, or compensation transactions.

6. The system of any one of claims 1 -5, wherein the coordinator automatically releases payment or credit to the node upon successful verification of the proof.

7. The system of any one of claims 1 -6, wherein the node can operate with other nodes in parallel groups, each producing independent proofs of task completion that are verified by the coordinator.Attorney Docket No. 11855-002W018. The system of any one of claims 1-7, wherein the secure module and resource monitor are co-located within a single node.

9. The system of any one of claims 1-8. wherein the resource monitor comprises a trained Al model executing within a secure module, the trained Al model configured to generate semantic features from sensor measurements for comparison against verification parameters10. The system of any one of claims 1-9, wherein the verification parameters specify a sequence of transitions and associated timing tolerances, and the proof engine generates a cryptographic proof that the sequence of transitions conform to the specified sequence.

11. The system of any one of claims 1-10, wherein a synchronization mechanism supports a global time mode in which a node verifies task execution using an absolute or quasi-absolute timing reference, the task verification proof further comprising a timing proof indicating that the node's local clock was within a permitted skew relative to the timing reference.

12. The system of any one of claims 1-11, wherein the synchronization mechanism supports a relative phase alignment mode in which nodes derive a shared epoch or phase marker without reference to absolute time, and the proof engine verifies that the physical output is aligned with the assigned phase or beat index within a phase-error tolerance.

13. The system of any one of claims 1-12, wherein the synchronization mechanism supports a coarse or asynchronous timing mode in which verification is performed using local timestamps, counters, or externally observable triggers without requiring a globally shared clock.

14. The system of any one of claims 1-13. wherein the task verification proof further comprises timing metadata selected from the group consisting of: local timestamps, event counters, drift estimates, phase offsets, beat indices, or timing-quality metrics.

15. The system of any one of claims 1-14. further comprising an execution attestation mode in which the secure module generates a cryptographic execution log that recordsAttorney Docket No. 11855-002W0121.actuator commands and internal status information without requiring measurement of a physical output by the resource monitor.

16. The system of any one of claims 1-15, wherein the secure module generates authenticated high-frequency sensor samples and produces a window-level commitment summarizing the samples, the commitment being verifiable against selectively disclosed samples during an audit.

17. The system of any one of claims 1-16, wherein a verifier performs selective audits by requesting specific sample indices or ranges and validating the disclosed samples against a Merkle root or chained-hash commitment included in the task verification proof.

18. The system of any one of claims 1-17, wherein the secure module authenticates sensor data from an external sensor using a digital signature, message authentication code, secure timestamp, or challenge-response protocol.

19. The system of any one of claims 1-20, wherein the secure module performs multi-sensor fusion by combining measurements from two or more sensors selected from the group consisting of: optical sensors, IMUs, electrical sensors, magnetic encoders, microphones, or env i ron mental s ens ors.

20. The system of any one of claims 1-19, wherein the proof engine generates the task verification proof based on fused sensor data derived from both internal and external sensors operating at different, trust levels.

21. The system of any one of claims 1-20, wherein the node identity comprises a hierarchical key structure derived from a root secret or seed phrase, the hierarchy including one or more subordinate keys for proof signing, capability issuance, or secure communication.

22. The system of any one of claims 1-21, wherein the node identity is compatible with Ethereum-sty le elliptic-curve key systems and the public component of the identity key is stored on a ledger to enable decentralized authentication.Attorney Docket No. 11855-002W0123. A method for verifying task execution in a distributed or centralized network, comprising:30.assigning, by a coordinator, task parameters and expected bounds to anode: executing, by a secure module within the node, the assigned task;31.eliciting and capturing, by a resource monitor, a physical output of the task; comparing, by a proof engine within the secure module, the physical output with the expected bounds;32.generating, by the proof engine, a cryptographic proof of correctness (e.g., signature or zero-knowledge proof);33.transmitting the proof to the coordinator;34.optionally recording a digest of the proof on a decentralized ledger; and verifying, by the coordinator, the proof and recording the verified result.

24. The method of claim 23, further comprising:36.computing, by the secure module, a deviation value between measured and expected results and signing a tuple of task identifier, measured value, target value, and pass / fail status.

25. The method of claim 23 or 24, wherein verification comprises batch-processing a plurality of proofs and committing their digests to the ledger in a single transaction.

26. The method of any one of claims 23-25, wherein the network comprises mobile nodes, each node including an actuator and sensor that verify phase or timing alignment within a predefined tolerance.

27. The method of any one of claims 23-26, wherein proof generation and verification employ asymmetric cryptography using Ed25519 signatures or equivalent schemes.

28. The method of any one of claims 23-27, wherein task verification is performed without reliance on a centralized authority.

29. The method of any one of claims 23-28, wherein compensation is automatically distributed to nodes whose proofs are verified as valid.Attorney Docket No. 11855-002W0130. The method of any one of claims 23-29, wherein generating the cryptographic proof further comprises executing an attested Al inference model within the secure module to produce feature-level or classification-level measurements of the physical output.

31. The method of any one of claims 23-30, wherein the physical output comprises a red, yellow, or green traffic-signal illumination pattern and the secure module verifies that the measured illumination matches the commanded state within a predetermined tolerance.

32. The method of any one of claims 23-31, wherein the task window and verification window are defined with sub-millisecond precision relative to a global timing reference, and verifying the proof comprises checking that the node’s reported timing error is below a predetermined threshold.

33. The method of any one of claims 23-32, wherein the task window and verification window are defined relative to a shared epoch derived from timing beacons exchanged among nodes, and verifying the proof comprises evaluating phase alignment or beat index consistency.

34. The method of any one of claims 23-33, wherein the task window and verification window are defined using coarse timing constraints expressed as minimum or maximum delays, event ordering, or deadlines based on local time, and verifying the proof comprises determining whether the reported execution occurred within the specified constraints.

35. The method of any one of claims 23-34, wherein generating the cryptographic proof further comprises including one or more timing-quality metrics indicating oscillator stability, drift correction applied, or timing-source confidence.

36. The method of claim 2, further comprising:49.generating, by the secure module, an execution attestation record that includes a hash of actuator commands, timestamps, and a status code, and signing the record with a key bound to an attested software image, wherein verification of the record provides assurance that the assigned task was executed as commanded, even in the absence of explicit physical output measurement. Attorney Docket No. 11855-002W0137. The method of any one of claims 23-36, further comprising:51.grouping sensor samples into windows, generating a cryptographic commitment for each window, and transmitting only a window-level proof unless a verifier issues a challenge requiring disclosure of individual samples.

38. The method of any one of claims 23-37, wherein failure of a node 102 to produce selectively requested samples or integrity metadata results in reduction of credit, revocation of capability keys, or exclusion from subsequent tasks.

39. The method of any one of claims 23-38, further comprising:54.deriving, by the secure module, a capability key from anode’s root identity key based on an epoch identifier, credit state, or task policy, and authorizing task execution only upon verification of the capability key.

40. The method of any one of claims 23-39, wherein the secure module derives subordinate keys from a root identity key using a hierarchical deterministic derivation function, and uses the subordinate keys for signing task verification proofs, encrypting communication, or authorizing participation in distributed timing or audit protocols.

41. The method of any one of claims 23-40. further comprising:57.authenticating sensor data from a semi-trusted external sensor using cryptographic integrity metadata and integrating the authenticated data with internal sensor measurements during the verification process.

42. A system configured to perform any one of the methods of claims 23-41.

43. A method configured to execute the system of any of the systems of claims 1-22.

44. A non-transitory computer-readable medium having instructions stored thereon, wherein execution of the instructions by a processor causes the processor to execute the systems of any one of claims 1-22 or the methods of any of claims 23 - 41.

Images