> ## Documentation Index
> Fetch the complete documentation index at: https://docs.layerzero.network/llms.txt
> Use this file to discover all available pages before exploring further.

# LayerZero Scan Swagger API

> Technical reference for LayerZero Scan Swagger API. Complete API documentation, function signatures, and implementation details for LayerZero V2. API documen...

The LayerZero Scan API lets you programmatically look up crosschain messages and transactions. You can search by message ID, transaction hash, GUID, wallet address, or OApp address. Results include message state, source and destination transaction details, DVN verification status, and pathway configuration.

Use it to track bridging activity, check message progress, or feed LayerZero data into your own dashboards.

## Available Methods

The API exposes endpoints under a versioned path (e.g., `/v1/`), including:

* **`/messages/latest`**\
  Get the most recent messages.
* **`/messages/pathway/{pathwayId}`**\
  Retrieve messages associated with a specific pathway.
* **`/messages/tx/{tx}`**\
  Lookup messages using a transaction hash.
* **`/messages/status/{status}`**\
  List messages filtered by their current status.
* **`/messages/month/{date}`**\
  Get messages or statistics for a given month.
* **`/messages/oapp/{eid}/{address}`**\
  Fetch messages by endpoint ID and OApp address.
* **`/messages/guid/{guid}`**\
  Lookup messages by their unique GUID.
* **`/messages/wallet/{srcAddress}`**\
  Retrieve messages initiated by a specific wallet address.
* **`/openapi`**\
  Access the full OpenAPI specification for further integration details.

For interactive testing, refer to the Swagger UI for your network:

* **Testnet:** [https://scan-testnet.layerzero-api.com/v1/swagger](https://scan-testnet.layerzero-api.com/v1/swagger)
* **Mainnet:** [https://scan.layerzero-api.com/v1/swagger](https://scan.layerzero-api.com/v1/swagger)

## Response status reference

Each message returned by the API has status fields at multiple levels: a top-level message status, and sub-statuses for the source, verification, and destination stages. These tell you exactly where a message is in its lifecycle.

For a high-level overview of what each message status means and how to debug it, see [Message Statuses Overview](/v2/concepts/troubleshooting/debugging-messages#message-statuses-overview).

### Message status

The `status.name` field on each message object:

| Status                 | Description                                                 |
| ---------------------- | ----------------------------------------------------------- |
| `INFLIGHT`             | Waiting for source confirmation, verification, or execution |
| `CONFIRMING`           | Destination transaction submitted, waiting for finality     |
| `DELIVERED`            | Delivered and executed on the destination chain             |
| `FAILED`               | Delivered but execution failed on the destination chain     |
| `BLOCKED`              | Cannot progress due to configuration issues                 |
| `PAYLOAD_STORED`       | Payload stored on destination, awaiting manual execution    |
| `APPLICATION_BURNED`   | Burned by the receiving application                         |
| `APPLICATION_SKIPPED`  | Skipped by the receiving application                        |
| `UNRESOLVABLE_COMMAND` | Command cannot be resolved (lzRead only)                    |
| `MALFORMED_COMMAND`    | Command is malformed (lzRead only)                          |

### Source status

The `source.status` field tracks the source transaction through finality:

| Status                       | Description                                                                                |
| ---------------------------- | ------------------------------------------------------------------------------------------ |
| `WAITING`                    | Waiting for the source transaction to appear on-chain                                      |
| `VALIDATING_TX`              | Transaction found; waiting for block confirmations to reach the configured finality window |
| `SUCCEEDED`                  | Transaction confirmed on-chain after the configured finality window                        |
| `WAITING_FOR_HASH_DELIVERED` | Waiting for transaction hash delivery (internal processing)                                |
| `UNRESOLVABLE_COMMAND`       | Command cannot be resolved (lzRead only)                                                   |
| `MALFORMED_COMMAND`          | Command is malformed (lzRead only)                                                         |

### Verification status

The `verification.dvn.status` field tracks DVN quorum progress:

| Status           | Description                                      |
| ---------------- | ------------------------------------------------ |
| `WAITING`        | Waiting for DVN verifications                    |
| `QUORUM_REACHED` | Required DVN quorum reached, pending commit      |
| `SUCCEEDED`      | Verifications committed on the destination chain |

The `verification.sealer.status` field tracks the commit (sealing) of DVN verifications on the destination chain:

| Status          | Description                                      |
| --------------- | ------------------------------------------------ |
| `WAITING`       | Waiting for verifications to be committed        |
| `VALIDATING_TX` | Commit transaction submitted                     |
| `SUCCEEDED`     | Verifications committed on the destination chain |
| `FAILED`        | Commit transaction failed                        |

Individual DVN statuses are under `verification.dvn.dvns[address].status`:

| Status                   | Description                            |
| ------------------------ | -------------------------------------- |
| `WAITING`                | DVN has not yet submitted verification |
| `VALIDATING_TX`          | DVN verification transaction submitted |
| `SUCCEEDED`              | DVN verification confirmed             |
| `WAITING_FOR_ULN_CONFIG` | Waiting for ULN configuration          |
| `FAILED`                 | DVN verification failed                |

### Destination status

The `destination.status` field tracks `lzReceive` execution on the destination chain:

| Status                           | Description                                      |
| -------------------------------- | ------------------------------------------------ |
| `WAITING`                        | Waiting for execution                            |
| `VALIDATING_TX`                  | Execution transaction submitted, confirming      |
| `SUCCEEDED`                      | Executed on the destination chain                |
| `FAILED`                         | Execution failed on the destination chain        |
| `SIMULATION_REVERTED`            | `lzReceive` or `lzCompose` simulation reverted   |
| `PAYLOAD_STORED`                 | Payload stored, requires manual execution        |
| `RESOLVED_PAYLOAD_SIZE_NOT_PAID` | Resolved payload size fee not paid (lzRead only) |

The `destination.nativeDrop.status` field tracks native token drops:

| Status          | Description                       |
| --------------- | --------------------------------- |
| `WAITING`       | Native drop not yet executed      |
| `VALIDATING_TX` | Native drop transaction submitted |
| `SUCCEEDED`     | Native drop executed              |
| `FAILED`        | Native drop failed                |
| `N/A`           | No native drop for this message   |

The `destination.lzCompose.status` field tracks composed message execution:

| Status                           | Description                        |
| -------------------------------- | ---------------------------------- |
| `WAITING`                        | `lzCompose` not yet called         |
| `VALIDATING_TX`                  | `lzCompose` transaction submitted  |
| `SUCCEEDED`                      | `lzCompose` executed successfully  |
| `FAILED`                         | `lzCompose` execution failed       |
| `SIMULATION_REVERTED`            | `lzCompose` simulation reverted    |
| `N/A`                            | No compose for this message        |
| `WAITING_FOR_COMPOSE_SENT_EVENT` | Waiting for the compose sent event |

### Checking transaction finality

To check whether a source transaction has reached finality, query the message by transaction hash and look at `source.status`:

```bash theme={null}
curl -X 'GET' \
  'https://scan.layerzero-api.com/v1/messages/tx/{txHash}' \
  -H 'accept: application/json'
```

The `source.status` field progresses as:

```
WAITING → VALIDATING_TX → SUCCEEDED
```

* **`VALIDATING_TX`**: The transaction has been found on-chain but the configured block confirmations have not been reached yet. DVNs will not begin verification until this completes.
* **`SUCCEEDED`**: The required confirmations have passed. The transaction is finalized and the message is progressing through verification and execution.

For OFTs, once `source.status` is `VALIDATING_TX` or later, the token debit (burn or lock) has occurred and the `PacketSent` event has been emitted. See [OFT atomicity](/v2/concepts/troubleshooting/debugging-messages#message-lifecycle) for more detail.