[WIP] Track C — feat(plugins): depin-attest — T0/T1 device-attested sensor readings#115
Open
Yashb404 wants to merge 3 commits into
Open
[WIP] Track C — feat(plugins): depin-attest — T0/T1 device-attested sensor readings#115Yashb404 wants to merge 3 commits into
Yashb404 wants to merge 3 commits into
Conversation
…sion gap
- Replace serde_json::to_vec(&reading) with an explicit pipe-delimited
canonical string for signature verification. Signing "the JSON" was
fragile: serde's derived Serialize output is not guaranteed to match
what a non-Rust device (C, Python, embedded firmware) would produce for
the same logical reading, meaning every genuine external device's
signature would likely fail to verify.
- Replace `value: f64` with `value_str: String` in SensorReading. The
device now transmits and signs the exact string representation it
chose, rather than the plugin re-deriving f64 formatting via `{}`
and hoping it matches the device's own formatter (Rust's shortest-
round-trip vs. e.g. C's fixed-decimal printf-style output would not
byte-match). Numeric validity (finite, parseable) is still checked
separately from the signature path.
- Reject '|' explicitly in sensor_id and unit (free-form string fields)
to prevent delimiter-collision signature forgery, where two distinct
logical readings could serialize to an identical canonical byte
string and thus share a valid signature. value_str and timestamp are
safe by construction, since a value that parses as finite f64/i64
cannot contain '|' — documented inline in validate_reading.
- Update memo text construction and all provenance tests to use the new
canonical format and value_str field.
All 27 tests pass. No wasm-target changes required — pure core only.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR aims to do
Adds
depin-attest, a ZeroClaw tool plugin for the Solana bounty (Track C —DePIN & the physical edge). Given a sensor reading, it cryptographically
verifies the reading was actually produced by a registered physical device
(Ed25519 signature check against a config-registered device pubkey) before
constructing an unsigned, nonce-anchored Solana transaction for a human to
sign.
Custody tier: T0/T1 only — no signing, no key custody beyond the device's
own signing keypair (which never touches this plugin; it only verifies).
Core focus: most sensor-attestation designs trust that a reading claiming to
come from
device_id: Xactually came from device X. This plugin closesthat gap — a reading isn't attested at all unless its signature verifies
against a known, registered device pubkey. Any device host (phone, Pi,
ESP32) can produce readings; sensor acquisition is deliberately kept outside
the plugin (an SOP/Skill concern), while the plugin's job is limited to
provenance verification, staleness checking, and transaction construction.
Pure-core provenance/validation logic (
reading.rs,provenance.rs) is written and host-tested; transaction construction andthe wasm shim are in progress. Full README (threat model, wiring diagram,
injection transcript) to follow in subsequent commits on this PR.
Feedback on the provenance/signature-verification approach welcome before I
go further — particularly whether device-pubkey registration via
__configis the right pattern versus anything more standard alreadyemerging in the ecosystem for this track.