Skip to main content
Glama

dero_forge_demo_proof

Read-only

Build a forged DERO proof string for any transaction, ring slot, and amount to show that explorer 'Verified ✓' status reflects local math, not chain consensus. Use alternative amounts to refute claims of minted coins.

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_hashNoTX hash to forge against. Daemon fetches the TX hex + ring members. Mutually exclusive with tx_hex.
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).
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
Behavior5/5

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

Goes beyond annotations by detailing that the tool is read-only, never broadcasts or mutates state, performs a self-check before returning, and references internal implementation. Discloses all relevant behavioral traits.

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

Conciseness4/5

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

The description is comprehensive but somewhat verbose. However, it is well-structured with clear sections (purpose, when to call, math, input requirements, output) and front-loaded with the main purpose. Almost every sentence adds value.

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 description fully covers the tool's purpose, usage, behavior, parameters, and output format (including diagnostic fields). Given the complexity and absence of an output schema, it provides all necessary information for an agent to use the tool correctly.

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?

While the input schema already has descriptions, the tool description adds significant value: explains mutual exclusivity, default values, valid ranges (ring_slot), and the effect of negative amounts. Provides context beyond the schema.

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 clearly states the tool's purpose: to build a forged `deroproof…` display object for any chosen transaction, ring slot, and amount. It distinguishes from sibling tools like `dero_decode_proof_string` by focusing on forging rather than decoding.

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

Usage Guidelines5/5

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

Provides explicit when-to-use scenarios (user questions about 'Verified ✓') and mentions it's useful for reproducing demonstrations. Also details critical input requirements (mutual exclusivity of tx_hash/tx_hex) and defaults, guiding proper invocation.

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

Install Server

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