Skip to main content
KineticVM separates the person who owns a machine from the key that machine signs with, and it puts every payment through a contract the device cannot rewrite. This page is the boundary of that design. The contracts are on Monad testnet and have not been audited. Amounts in a vault are testnet MON.

​
What the protocol holds

ownerOf on the ERC-8004 Identity Registry is the owner. Telegram pairing, chain.owner in the config, and physical access to the board do not transfer the vault. Selling the machine is transferring the NFT, which makes activeDevice revert until the new owner links a device.
The device key signs claim tickets, action proofs, and its own transactions. No KineticVM contract approves that key on the agent NFT. It cannot transfer the identity, and it cannot open a validation by itself. The owner approves the attestor.
pay is the only vault function that sends MON to a third party. It requires the active device, an unpaused vault, an allowlisted recipient, and room under both caps. There is no second path for the device to move the balance.
Lowering caps, pausing, removing a recipient, and withdrawing are direct owner transactions. Raising caps, adding a recipient, and unpausing need the owner in person or an EIP-712 signature that the vault checks. A personal signature is rejected. The device can relay the signed call. It cannot sign it.
An operation line is canonicalized before it is signed, and the same line is what gets stored. A buyer hashes the line and compares it to the Validation Registry. The host does not add chat ids, wallets, or codes.

​
What it does not hold

An attestation with response 100 proves a signature by the bound device key. It does not prove the actuator moved, the sensor was calibrated, or the plugin told the truth. A marketplace listing does not add that proof. Verification replays the signature check. It does not replay the physical event. The device key, in the default software signer, is an encrypted file on the device. Someone who can read that file and the secret store can sign as the device until the owner revokes or rotates the key. A secure element such as the SE050 is the planned place for that key. The signer interface is the same either way. The element is not what this testnet build uses. Plugins run in a WebAssembly sandbox, with permissions and an egress list the operator grants. A permission you grant is a permission the plugin has. Review a package before you install it, and keep http_client and filesystem permissions off unless a tool needs them.

​
Controls when something is wrong

Pausing the vault does not delete the device key, and estop does not pause the vault. Use the control that matches the thing you are stopping.

​
Data you should not put in a record

Anything in an operation record can be listed and sold. Declare only the fields a buyer of that dataset should see. Do not declare names, chat ids, wallet addresses, access codes, or precise locations unless publishing them is the point. The marketplace key is an encrypted config secret. The device sends it as a bearer token. Treat a leaked kvm_ key the way you would treat a leaked API key: it can publish listings for that agent until the NFT moves, which revokes stale keys, or you stop using it. The key cannot spend the vault and cannot sign attestations.