Skip to main content
POST
Synchronous endpoint

Networks: all supported EVM chains, plus TRON. See Supported Chains.

Assess a transaction before signing, identify the requested action, and return a direct ALLOW, WARN, or BLOCK recommendation.
This established integration keeps its current request and response field names. Do not rename protocol or simulation fields such as gasLimit, tokenName, or tokenPriceUSD.
Forwarding an unsigned TronWeb transaction? Use TRON Raw for a separate request form.

Quick Start

More Request Examples

The examples below use the default simulate: true. Send exactly one flattened transaction in evm_transactions.

EVM

TRON

Request Fields

string
required
Your HashDit API key. Missing or invalid keys return HTTP 401. Keep the key on a trusted server.
string
Full URL of the dApp that initiated the transaction. Recommended because the domain can provide a risk signal even when the destination contract is new. Alias: dappUrl.
object[]
required
Exactly one flattened transaction. Use this shape for EVM, or for TRON when you have already converted the transaction into the common format. Alias: transactions.
boolean
default:"true"
Keep true for the fullest assessment. Set to false only when you want a verdict without execution results and accept that execution-dependent risk signals are unavailable.

Response Fields

string
required
API result code. "0" indicates success; non-zero values indicate an error.
string
required
Request status. A successful completed response returns "ok".
object
required
Summary of the action requested by the submitted transaction. This describes intent; it is separate from the security verdict and simulation result, and remains available when simulation is disabled or cannot complete.
integer
required
Risk score from 0 to 5; higher values indicate greater risk.
string
required
Human-readable risk level corresponding to overall_score.
Signing-flow decision: ALLOW, WARN, or BLOCK.
object[]
Triggered security findings. Use name for logic and description for display.

How to Use the Response

Transaction intent is not a security verdict. Use transaction_info to explain what the user is being asked to do, security to decide whether the transaction is safe to sign, and simulation results only to describe predicted execution effects. Use recommended_action as the signing decision: Show every risk_details[].description so the user understands why a warning or block was returned. Use risk_details[].name for application logic because identifiers are stable while descriptions can improve over time. Use transaction_type for the transaction title and main client flow: An explicit other is authoritative; do not replace it by matching primary_action, a function name, a selector, or a risk finding. If an older response omits transaction_type, you may fall back to your existing title logic. Use a generic title for an unrecognized future category. primary_action and actions provide more detailed intent and can include values such as execute, batch, contract_call, or unknown. Clients should accept additional action values so new classifications do not break an existing integration. Use decoded_call when available for a more specific display, and preserve large decoded integer values as strings to avoid precision loss.

Risk Level Reference

Numeric Fields

Every int | string field in this request — value, gas, gas_price, max_fee_per_gas, max_priority_fee_per_gas, nonce, type, block_height, token_id, token_value, and the amount inside freeze_balance and delegate_resource — accepts all three of: The three are equivalent. Send strings above 2^53 so JavaScript callers do not lose precision. A hex string must carry the 0x prefix: "f4240" is a 400.

Errors and Retry Guidance

Correct 400 errors before retrying. Back off with jitter after 429; retry 500 only a bounded number of times. Error responses include a detail or message explaining the failure: