The device runtime
The runtime is a single Rust binary,kinetic. On a device it runs as one long-lived process, kinetic start, which brings up:
Agent loop
Agent loop
A language model with a set of tools. The default autonomy is supervised: medium-risk actions need approval and high-risk actions are blocked. Workspace boundaries and a command allowlist sit in front of the shell. Supported providers are Anthropic, OpenAI, Gemini, OpenRouter, Ollama, Hailo-Ollama, and any OpenAI-compatible endpoint.
Device signer and chain client
Device signer and chain client
A secp256k1 key generated on the device the first time the chain is opened, stored encrypted in
device.key beside the config, and never logged or exported. The signer sits behind one interface so a secure element (NXP SE050) can replace the software key without changing anything above it. The chain client signs digests that the contracts compute and submits transactions from the device key.Channels
Channels
Telegram for the owner and for customers. MQTT, webhooks, and filesystem events for machines and SOP triggers. ACP for editor clients. An HTTP and WebSocket gateway for local clients.
Hardware
Hardware
GPIO on Raspberry Pi, and a JSON-over-serial protocol for ESP32, Pico, Nucleo, and Arduino boards. Boards can push events, such as a keypad code, that start a procedure.
The contracts
Three KineticVM contracts sit on top of two canonical ERC-8004 registries. They are one shared installation: every device uses the same three addresses. Claiming a device does not deploy anything.
Addresses are on the Deployments page.
The lifecycle of a device
1
Install and configure
kinetic quickstart stores the device name, the owner wallet, the Telegram bot, the model, and the starting caps. No key exists yet.2
Pair
kinetic start prints a one-time code. The owner sends /bind <code> to the bot. That chat becomes the owner chat.3
Create the key and sign a claim ticket
The device generates its key and signs an EIP-712
ClaimTicket(device, owner, nonce, deadline). The ticket proves the device holds the key and names exactly one owner. It expires within a day.4
Claim
The owner opens the claim link and calls
claim. The registry mints the ERC-8004 identity, transfers it to the owner, binds the device, and initializes the vault caps. The owner approves the attestor as an operator on the NFT, and sends the device its first gas.5
Fund
Anyone can deposit MON into the agent’s vault account. Only the owner can withdraw.
6
Operate
The agent acts through tools. Successful actuator calls are attested automatically. Builder-defined operations are attested through
monad_attest and appended to the local operations file. Payments go through vault_pay, which calls DeviceVault.pay. When the device’s own gas runs low, it tops itself up from the vault, inside the caps.7
Govern
The owner tightens limits or pauses from their wallet, and loosens limits, adds recipients, or unpauses by signing an EIP-712 message that the device relays. Every owner command re-reads the chain.
8
Monetize
/sell_data lists the attested operation records on the marketplace. Buyers verify each row against Monad, pay the owner, and download the file.9
Transfer, revoke, or rotate
Selling the NFT moves the machine. Revoking drops the device key. Rotating swaps in a new key. See Ownership.
Who can do what
The table below is the core of the security model. Every row is enforced by a contract, not by the runtime.“Owner” always means the current
ownerOf on the ERC-8004 Identity Registry. No contract caches it. If the NFT moves, authority moves with it on the next block.Where to go next
Identity
Claim tickets, binding, and what happens on transfer.
Device Vault
Caps, the daily window, allowlists, and signed loosening.