Skip to main content
Glama

dero_forge_demo_proof

Read-only

Forge a deroproof string for any transaction and amount to show a Verified ✓ badge only reflects display data, not chain-minted coins. Compare forged vs original proofs side-by-side to refute inflation claims.

Instructions

Composite: build a fresh deroproof… display object for ANY chosen transaction, ring slot, and amount — including negative amounts that uint64-wrap into the trillions. The forged string is constructed locally from public chain data (no wallet, no keys, no broadcast). On an unpatched explorer it shows Verified ✓ for the chosen amount; on the chain, nothing has changed.

When to call: when a user pastes a deroproof… string and asks "does Verified ✓ mean the chain minted these coins?" Forge an equivalent string for the same TX with a different amount and show the result side-by-side — that is the most direct refutation. Also useful for reproducing the docs/integrity/inflation-claim Part 3 demonstration on arbitrary inputs.

Math: blinder = C[ring_slot] − amount × G, then bech32("deroproof", version || blinder || CBOR({HH: zeros, VU: uint64})). The tool runs the same equation proof.Prove() checks at proof/proof.go:88-95 and self-verifies before returning a string. If the self-check fails, the tool throws rather than emit a string that would not verify.

Input Requirements (CRITICAL):

  • Exactly ONE of tx_hash or tx_hex MUST be provided. tx_hash triggers a daemon fetch (and surfaces the receiver address); tx_hex skips the daemon and uses the raw bytes the caller already has.

  • ring_slot is OPTIONAL (default 0). Must be in [0, ring_size).

  • amount_dero is OPTIONAL (default "-1"). Signed decimal with up to 5 fractional digits, e.g. "-1", "1000000", "-2200000.00181". Negative values produce uint64 wraparounds that unpatched explorers render as positive trillions.

Output: { forged_proof_string, target_amount: { dero, atoms_signed, atoms_uint64 }, ring_slot, ring_size, ring_receiver_address, math: { C_slot_hex, amount_x_G_hex, blinder_hex }, self_check: { verified, method }, explorer_display_amount, context_note, related_docs, _diagnostics }. ring_receiver_address is null when tx_hex was passed (the hex carries publickey pointers, not addresses).

READ-ONLY: this tool never broadcasts, never touches a wallet, never mutates chain state. It computes a string from public inputs and returns it. Annotation readOnlyHint: true is preserved. PREFER citing the returned related_docs (the integrity rebuttal pages) in any agent response — readers should understand the forged string is a display-layer object, not a consensus event.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tx_hexNoRaw TX bytes as hex (skip the daemon round-trip). Mutually exclusive with tx_hash. When provided, ring_receiver_address is omitted from the response (the hex carries publickey pointers, not full addresses).
tx_hashNoTX hash to forge against. Daemon fetches the TX hex + ring members. Mutually exclusive with tx_hex.
ring_slotNoWhich ring slot 0..ring_size-1 the forged proof should resolve to. Defaults to 0.
amount_deroNoTarget display amount in signed DERO (5 fractional digits = atomic precision). Negative values demonstrate the uint64 wraparound. Default "-1".-1
Install Server

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description discloses that the tool never broadcasts, never touches a wallet, never mutates chain state, constructs the string locally from public data, self-verifies before returning, and throws on self-check failure. This is rich behavioral context that annotations alone do not provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but densely structured with sections for purpose, when to call, math, input requirements, output, and read-only behavior. Every section earns its place, and the most important scoping and safety information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has four interdependent parameters and no output schema, yet the description compensates fully by enumerating all returned fields, explaining when ring_receiver_address is null, describing the self-check, listing related_docs, and noting diagnostics. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds critical semantics: exactly one of tx_hash or tx_hex must be provided despite no required schema fields, including the daemon-fetch vs raw-hex tradeoff. It also explains defaults, ring_slot bounds, fractional decimal format, and the negative-amount uint64 wraparound behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: forge a deroproof display object for an arbitrary transaction, ring slot, and amount. It clearly distinguishes itself from chain-inspection siblings by framing the result as a display-layer object and noting 'on the chain, nothing has changed.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'When to call' section is explicit: use it when a user pastes a deroproof string and asks whether Verified means the chain minted coins, and forge a side-by-side refutation. It also names the docs reproduction use case. It does not enumerate when not to call or name alternatives, but the trigger context is specific enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DHEBP/dero-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server