Features

Pre-sign transaction risk check from raw transaction

mab.xyz provides a pre-sign transaction risk check through the /v1/analysis/tx-risk-raw endpoint. This feature lets a wallet, frontend, or compliance workflow submit a raw transaction payload before broadcast and receive an immediate risk-oriented interpretation of what the transaction is about to touch on-chain.

The endpoint accepts a raw transaction in hexadecimal format. It can process:

• Signed transactions, for which the sender address is recovered from the signature.

• Unsigned transactions, for which the caller must explicitly provide the sender_address.

The backend then decodes the transaction format, supporting legacy transactions as well as typed Ethereum transactions such as EIP-2930 and EIP-1559. From the decoded payload, it reconstructs the call object used for simulation, including the destination address, calldata, value, gas settings, and transaction type.

What the endpoint does:

1. Decodes the raw transaction: The system validates the hex input and parses the transaction payload. Invalid or malformed transactions are rejected with a validation error.

2. Determines the sender: If the transaction is signed, the sender is recovered automatically. If it is unsigned, the request must include the sender address so the simulation can be performed in the correct execution context.

3. Simulates the transaction: The reconstructed call is executed against the configured chain state using the selected block_tag (default: latest).

4. Extracts touched contracts: The simulation identifies the set of contracts touched by the execution path, including transitive calls.

5. Checks contract verification: The system evaluates whether each touched contract is verified. Any unverified contract in the call chain is considered dangerous regardless of interaction history.

6. Checks interaction novelty: For each touched address, the system evaluates whether the interaction appears to be a first-time interaction according to the configured interaction type and block bounds. The check distinguishes between confirmed first-time interactions (where historical data exists and proves novelty) and interactions where the history is simply missing from the database. A contract's interaction with itself is always treated as known.

Returned information includes:

• An overall status of OK, DANGEROUS, or POTENTIAL_DANGEROUS:

  • DANGEROUS — any touched contract is unverified, or a confirmed first-time contract-based interaction was detected.

  • POTENTIAL_DANGEROUS — no confirmed danger, but interaction history is missing for at least one contract-based check, so a definitive assessment cannot be made.

  • OK — all checked contract-based interactions have existing history and none are first-time.

• An interaction_status map showing, for each interaction mode (sender_direct, sender_transitive, contract_direct, contract_transitive), whether it is ok, dangerous, potential_dangerous, or not_checked.

• A per-address details list containing:

  • the touched contract address

  • whether any checked interaction mode is first-time for that address

  • contract verification information, when available

  • call depth and call-type frequencies observed during the simulation

  • per-interaction-type first-time results

  • whether the first-time result was sourced from existing state (FOUND) or is currently absent (MISSING)

• A danger_reason indicating why the transaction was flagged:

  • UNVERIFIED — at least one touched contract is not verified. This takes priority over other reasons.

  • FIRST_TIME_INTERACTION — a contract-based first-time interaction was confirmed from existing history.

  • MISSING_HISTORY — interaction history is absent for at least one contract-based check, preventing a definitive assessment.

• A list of dangerous_interaction_types identifying the contract-based interaction types that confirmed a first-time interaction.

This feature is useful for wallet warnings, transaction preview, policy enforcement, and compliance screening. It turns a raw, low-level Ethereum transaction into an actionable assessment of which contracts will be touched and whether the interaction pattern appears novel or potentially risky before the transaction is sent on-chain.

Battery-included API calls

Our API is rate limited. Subscribers have an order of magnitude more API budget than free users.