One signed representation
Every observation uses deterministic CBOR, SHA-256, and an Ed25519 signature so any verifier can reproduce exactly what the device signed.
Vertices SDK · Physical AI & Economy of Things
Verifiable machines,
built from the device up.
We are building a Rust, Zephyr-ready trust layer for Physical AI and the Economy of Things—so constrained devices can create authenticated observations, prove their identity, and participate in the internet economy under explicit policy.
PROTOCOL / V0.1
IN DEVELOPMENT
01
Physical deviceSensor + secure credentials
02
Signed observationDeterministic CBOR + Ed25519
03
Public verificationCommitment anchored on Base
The product thesis
Physical AI needs evidence
it can trust.
Physical AI becomes useful when it can reason about a current, attributable signal from a real machine—not just data from an unknown source. A device should be able to answer three questions: Who am I? What did I observe? and, only once those answers are trustworthy, What am I allowed to buy?
Vertices supplies the embedded trust layer between physical systems and digital services. Our path is deliberately staged: open protocol → embedded identity SDK → Economy of Things infrastructure. Each step has a proof gate before the next begins.
What ships first
A compact protocol for trustworthy observations.
The first release proves one complete path from sensor data to an independently auditable public commitment.
Separate keys, separate jobs
Ed25519 proves the observation. A separately managed secp256k1 credential authorizes the Base transaction. Both can rotate independently.
Proof on-chain, data off-chain
Base records the commitment, sequence, and metadata reference. Raw sensor bodies stay off-chain and keep their application-specific format.
OBSERVATION
CANONICAL CBOR
ED25519
EIP-1559
BASE SEPOLIA
VERIFY
The roadmap
Four proof-driven chapters.
This is a sequence of evidence, not a feature checklist. Timing follows the success gates: we advance when the previous claim works on real hardware and can be verified by others.
01
Prove the protocol, then make the ESP32 real.
First, a desktop reference device signs, submits, and independently verifies a complete Base Sepolia flow. Then the unchanged protocol moves to an ESP32 with Wi-Fi, a sensor, two keys, and a monotonic sequence source.
Current focusDesktop end-to-end flow and ESP32 validation.
- Publish the SDK skeleton, registry contract, testnet details, and integration guide.
- Measure flash, RAM, signing latency, network overhead, energy, and recovery behavior.
- Keep production crates allocator-free and
no_stdunder cross-compilation.
Proof gateA third party can verify that device X signed an observation and its authorized machine account anchored it.
02
Root identity in hardware and bind it to firmware.
The signer abstraction becomes a real security boundary with an SE050 secure-element backend and a path to secure MCUs. Registration then links the device to an approved firmware measurement and provisioning state.
- Generate or provision non-exportable observation and EVM credentials.
- Demonstrate that private key material never enters application logic.
- Add privacy-conscious firmware measurement, update, and rollback policies.
STRETCH / P3A Add a versioned hardware-state attestation that can prove secure boot, lifecycle, anti-rollback, debug-lock, and approved firmware state.
Proof gateA verifier can link an observation to registered hardware running approved firmware—and reject an untrusted state.
03
Make identity operable across a device lifecycle.
Move from a demo credential to a fleet-ready operational model: factory provisioning, registration, operator assignment, ownership transfer, rotation, recovery, and retirement.
- Keep ownership, observation keys, economic accounts, and firmware signers as distinct roles.
- Prototype smart accounts only if session keys, recovery, or spend policy improve the customer case.
- Evaluate relaying and batching so devices can publish without each one managing ETH.
Proof gateA repeatable, auditable fleet flow publishes device evidence without per-device gas management.
04
Validate one customer use case, then enable one purchase.
We will choose a focused DePIN or device-manufacturer workflow where trusted machine data helps a Physical AI workflow unlock a real transaction. Only after that value is proven do we add constrained machine-to-machine commerce through x402.
- Run real hardware with a design partner in a specific sensor workflow.
- Create
vertices-x402as a transport-independent, allocator-free payment-policy engine. - Separate capability, spend limit, and immediate action intent before any signature is requested.
Proof gateA real device buys one narrowly scoped internet service under explicit policy—and a customer can explain why it is worth paying for.
Where this leads
Six concrete outcomes.
By the end of this roadmap, we intend to have a complete body of code, hardware evidence, operating practice, and customer learning.
- 01Rust SDK
A production-quality, allocator-free core with stable protocol, crypto, Base, and adapter boundaries.
- 02ESP32 reference
A real sensor producing signed observations and anchoring commitments on Base.
- 03Hardware-rooted keys
Secure-element and secure-hardware paths with non-exportable credentials.
- 04Verifiable machine identity
Hardware identity, firmware measurement, and optional state attestation in one model.
- 05Relayed publishing
A fleet-suitable route that removes per-device gas management.
- 06One policy-controlled purchase
An x402 service purchase completed by real hardware with a design partner.
Deliberate boundaries
What we are not building.
A general-purpose crypto wallet for IoT.
On-chain storage for raw or sensitive sensor data.
A multi-chain platform before the Base path proves useful.
Payments or physical actuation before identity and evidence are trustworthy.
Build with us