# 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://mab-xyz.gitbook.io/mab-xyz-docs/features.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.