Rohan Shield
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ROHAN_RELAYER_URL | Yes | The URL of the Rohan relayer handshake endpoint | |
| ROHAN_CONTRACT_ADDRESS | No | Midnight Preprod Contract Address |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| rohan_execute_handshakeB | Executes a confidential zero-knowledge state transition on Midnight Blockchain. Confidential parameters are automatically canonicalized (RFC 8785) and hashed in client RAM—never exposed on-chain or in model logs. |
| rohan_get_ledger_stateA | Reads the current anchored state of the Rohan Protocol smart contract on Midnight Preprod L1. Returns the state root, block height, and last mined transaction hash from memory cache. |
| rohan_get_transaction_historyB | Lists historical settlement transactions and receipts anchored on Midnight Preprod L1. |
| rohan_verify_commitmentA | Verifies a plaintext confidential payload against its SHA-256 digest using RFC 8785 JSON Canonicalization. Supply the inner payload digest, not the outer on-chain intentHash. Zero gas cost; runs in local memory. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool maps to a clearly distinct action/resource: executing a confidential state transition, verifying a commitment digest, reading the current ledger state, and listing transaction history. The boundary between reading ledger state and listing transaction history is clear from the descriptions.
All tools use the same rohan_ prefix followed by a consistent verb_noun pattern (execute_handshake, get_transaction_history, verify_commitment, get_ledger_state). The convention is predictable throughout.
Four tools is well-scoped for a focused blockchain protocol server, and each tool has a clear, non-redundant role. There is no padding or extreme thinness given the domain.
The surface covers core operations: execute, verify, read state, and list history. Minor gaps exist, such as direct transaction/receipt lookup by hash or richer protocol query operations, but agents can likely work around them via history and state reads.