Vtimestamp Write

vtimestamp-mcp-write

MCP server for creating vtimestamp proofs on the Verus blockchain.

Enables AI agents (Claude Desktop, VS Code, etc.) to create document timestamps on a VerusID — writing directly to the Verus blockchain via a local or remote daemon.

Looking for the read-only server? See vtimestamp-mcp — no daemon or wallet required.

Prerequisites

• Node.js 18+
• Verus daemon (`verusd`) running with:
• The identity's private key imported into the wallet
• RPC access enabled (default on localhost)

Installation

Claude Code

claude mcp add --transport stdio --scope user vtimestamp-write -- npx vtimestamp-mcp-write@latest

Claude Desktop

Add to your claude_desktop_config.json:

{

"mcpServers": { "vtimestamp-write": { "command": "npx", "args": ["-y", "vtimestamp-mcp-write@latest"] } } }

That's it — the server auto-detects your RPC credentials from VRSC.conf (see Configuration below).

VS Code

Add to your VS Code MCP settings:

{

"mcp": { "servers": { "vtimestamp-write": { "command": "npx", "args": ["-y", "vtimestamp-mcp-write@latest"] } } } }

Configuration

The server automatically reads RPC credentials from your local VRSC.conf file. No manual configuration is needed for most users.

Auto-detected `VRSC.conf` paths:

• macOS: ~/Library/Application Support/Komodo/VRSC/VRSC.conf
• Linux: ~/.komodo/VRSC/VRSC.conf
• Windows: %AppData%\Roaming\Komodo\VRSC\VRSC.conf

Environment Variables

All optional — only needed for non-standard setups or remote daemons.

Tools

vtimestamp_create

Create a new timestamp on a VerusID. Provide either a file path or text — the server computes the SHA-256 hash automatically.

Either file_path or text must be provided (mutually exclusive).

Example prompts:

• "Timestamp the file at /path/to/report.pdf on alice@"
• "Timestamp this text on alice@: I attest that invoice #4521 was approved"

Success response:

{

"success": true, "identity": "alice@", "hash": "a7f3b2c1...", "title": "Q4 Report", "transaction_id": "abc123...", "message": "Timestamp created successfully" }

Error cases:

• Identity not found → error with identity name
• Duplicate hash → error with existing block height and txid
• File not found → InvalidParams error
• RPC failure → error with daemon message

How It Works

The server connects to your Verus daemon (local or remote) to create on-chain timestamps. The daemon must have the identity's private key in its wallet to sign the updateidentity transaction.

AI Agent (Claude Desktop, VS Code, etc.)

│ stdio (JSON-RPC) ▼ vtimestamp-mcp-write (local) │ HTTP (JSON-RPC 1.0, with auth) ▼ Your Verus Daemon (verusd) ├── Has identity's private key in wallet ├── Signs and broadcasts updateidentity tx └── Local (127.0.0.1) or remote (VPS)

On-chain storage shape

As of v1.2.0, this server writes timestamps as public-encrypted entries under the VerusID's contentmultimap. Each timestamp produces a single entry under the proof.basic outer key (iJvkQ3uTKmRoFiE3rtP8YJxryLBKu8enmX) using the daemon's {data: {...}} envelope shorthand. The daemon expands that to an on-chain DataDescriptor with flags: 13 (HAS_OBJECTDATA | ENCRYPTED | HAS_IVK) — ciphertext in objectdata, plus published epk and ivk fields.

The metadata (sha256, title, description, filename, filesize) is JSON-stringified into a single message before encryption, so one decrypt call recovers all fields. Because the IVK is published on-chain (public-encrypted mode), anyone can decrypt these entries — no key sharing or wallet access is required for readers. See vtimestamp-mcp for the read side.

What this means for inspection:

• Inspecting the cmm via any read RPC (getidentity, getidentityhistory, getidentitycontent) returns the ciphertext descriptor, not readable strings.
• Recovering the original fields requires a decryptdata call passing the descriptor + the originating txid + retrieve: true. The daemon stores ciphertext as an indirect reference back to the writing transaction — the txid is part of the decrypt input.
• Verifying a hash against an identity does not require a wallet — only daemon RPC access to a node that has decryptdata whitelisted.

Legacy entries continue to work. Timestamps written by 1.1.x and earlier (plaintext per-field DataDescriptors with flags: 0) remain on-chain forever (cmm is append-only), and vtimestamp-mcp@1.2.0+ reads both shapes transparently.

For background, see How to Publish Encrypted Data on an Identity.

Daemon Setup

Local daemon

The simplest setup — verusd runs on the same machine as the MCP server. No configuration needed — credentials are auto-detected from VRSC.conf.

Remote daemon (VPS)

You can point the MCP server at a verusd instance running on another machine (e.g., a VPS). The daemon needs two config changes in its VRSC.conf:

1. Allow your IP: Add rpcallowip= (the daemon only accepts localhost by default)
2. Open the port: Ensure the RPC port (27486) is reachable through any firewalls

Then set the env var overrides (VERUS_RPC_URL, VERUS_RPC_USER, VERUS_RPC_PASSWORD) in your MCP config.

Important: RPC credentials are sent over plain HTTP. If connecting over the open internet (not a local network), use an SSH tunnel to secure the connection:

ssh -L 27486:127.0.0.1:27486 user@your-vps

Then use VERUS_RPC_URL=http://127.0.0.1:27486 as if it were local — the tunnel handles the rest.

Security Notes

• This server reads your `VRSC.conf` to auto-detect RPC credentials — no secrets are copied or stored elsewhere
• This server performs on-chain writes that cost a small transaction fee (default 0.0001 VRSC)
• The server only connects to your local daemon (or the URL you configure) — no data is sent elsewhere
• If connecting to a remote daemon, use an SSH tunnel rather than exposing the RPC port directly
• The sourceoffunds parameter can be used to control which address pays fees

License

MIT