Skip to main content
Telegram is the device’s control surface. The paired chat can ask the device anything in plain language, and it can use a fixed set of owner commands that read and change onchain state.
Telegram is a convenience, not the authority. Pairing a chat proves you control the Telegram account the device trusts. It does not prove you own the agent. Every command that loosens a limit still needs a signature from the owner wallet, checked by the vault contract.

​
Pairing

The first time kinetic start runs, the terminal prints a one-time code:
Send /bind 482913 to your bot. The device replies ✅ Telegram paired successfully! and stores your Telegram user id as the only peer it serves. Owner commands from any other chat get:
The old /link command is retired. The paired chat does not need it.

​
The commands

​
read
Shows the agent id, device and owner addresses, vault balance, spend in the current window, both caps, pause state, and explorer links for the five most recent attestations.
​
read or change
With no arguments, shows the current caps and pause state. With two MON amounts, /limits <per-tx> <daily>, proposes new caps. See Changing caps.
​
owner wallet
Replies with the exact call to make from the owner wallet: pause(<agentId>) on the vault. The device cannot pause on your behalf, by design: stopping a device must never depend on the device.
​
signed
Returns an EIP-712 digest for Unpause. Sign it with the owner wallet and send /resume <deadline> <signature>. The device relays the transaction.
​
signed
/approve <address> returns an EIP-712 digest for AllowRecipient. Sign it and send /approve <address> <deadline> <signature>. The device relays the transaction and the address can now receive vault payments.
​
link
Replies with a link to the deposit page for this agent’s vault account.
​
link
Replies with a link to the withdraw page. Connect the owner wallet there to withdraw.
​
conversation
Starts a data listing. The device asks for any listing detail it is not sure of, then lists its operation records on the marketplace. See Data listing.

​
The signing flow

Commands that loosen what the device can do use a two-message flow. The device does the chain work and pays the gas. The owner wallet only signs.
1

Ask

Send the command without a signature, for example /approve 0x2b1f…c9d0.
2

Receive the digest

The device reads the vault’s loosenNonce, sets a deadline one hour after the latest block, computes the EIP-712 digest on the vault, and replies:
3

Sign

Sign the 32-byte digest itself, with no message prefix. For example, with Foundry:
4

Send it back

Paste the command with the signature in place of SIGNATURE. The device submits the transaction and replies with its hash, for example 0x2b1f…c9d0 can receive vault payments. Transaction 0x….
A digest is valid once and only until its deadline. If another signed change lands first, the nonce moves and the old digest stops working. Ask again for a fresh one.
If the signature does not recover to the current owner, the vault reverts and the device replies:
You can always skip the relay. Any loosening function called directly from the owner wallet is authorized by the transaction itself, and the signature argument is ignored. For example, call unpause(<agentId>, 0, 0x) on the vault from the owner wallet.

​
Changing caps

/limits <per-tx> <daily> compares the proposal with the current caps:

​
Talking to the device

Anything that is not an owner command goes to the agent. You can ask it to check its identity, report the vault, or pay an allowlisted address within its caps. Tool calls that arrive over a chat channel, such as a vend, a plugin tool, a pin write, or an attestation, run without an approval card. Four tools always raise one first: shell, file_write, file_edit, and vault_pay. When the vault cannot cover the device’s gas, the device posts a message to the paired chat: