What this guide explains

Most plugin pages only say that an extension adds “more data” to Solscan. That is usually not enough. If you do not know where the data comes from, what each row means, or how to read it, you cannot turn the output into something useful.

So this guide is written in usage order: first what the plugin shows, then how it gathers the data, then how to interpret Landed By, Prev Leader, and Provider on a Solscan transaction page. After that, it explains why those fields work well together as a lightweight landing-analysis view.

What the plugin adds to Solscan

When you open a Solscan transaction page, the Node1 Solscan Plugin inserts an extra information block below the transaction metadata area. It currently adds three rows:

Landed By
Prev Leader
Provider

Those rows answer three separate questions:

  • Who landed this transaction.
  • What leader came right before that leader.
  • Whether the transaction appears to have landed through Jito, and if so, what tip was paid.

Landed By

Landed By shows the leader associated with the slot in which the transaction landed. The plugin packs endpoint and identity information into one compact row so the landing context is readable at a glance.

Display format:

IP | region | name | client_type | leader_pubkey

Example:

208.91.109.57 | Japan / Tokyo | Helius | Other | HEL1USMZKAL2odpNBj2oCjffnFGaYwmbGmyewGv1e2TU

From left to right, the fields mean:

IP

The visible IP address associated with that leader entry in the dataset.

region

The geographic label attached to that leader.

name

The validator or service label mapped to that leader.

client_type

The validator client classification currently mapped to that leader.

leader_pubkey

The leader pubkey itself, which can be copied directly from the plugin.

Prev Leader

Prev Leader shows the leader from the previous slot, using the same display format as Landed By.

If the previous slot is associated with the same leader pubkey as the current slot, the plugin displays Same.

That matters because not every transaction should be analyzed in isolation. If the previous slot leader is different, it helps you understand whether the landing context changed right before your transaction. If it is the same, the leader sequence did not change across the boundary the plugin is comparing.

Same

Provider

The Provider row shows the plugin’s provider-side interpretation of the landing path. Right now it has two main states:

Jito | Tip: <x> SOL

If the transaction is detected through Jito bundle APIs, the plugin marks it as Jito and shows the landed tip amount in SOL when that value is available.

Normal

If no bundle match is found, the plugin shows Normal.

This row is not trying to describe every possible routing path on Solana. Its purpose is narrower: show whether the transaction appears to be tied to Jito bundle landing and expose the visible Jito tip when available.

Copy behavior

  • The Landed By row copy button copies only the current leader pubkey.
  • The Prev Leader row copy button copies only the previous leader pubkey.
  • If Prev Leader is shown as Same, the previous copy button copies the current leader pubkey.

This is designed for quick operator workflow. In practice, the pubkey is usually the part you want to reuse for searches, analysis, filtering, or validator lookup.

How the plugin works

The plugin reads the transaction signature directly from the Solscan transaction page URL. From there, it gathers data in two paths and merges the results inline on the page.

Path one: leader and client information

  • The plugin calls the Node1 backend with the transaction signature.
  • The backend resolves the slot, finds the current leader, and finds the previous leader.
  • It returns metadata such as IP, region, name, and client type.

Path two: provider information

  • The plugin checks Jito bundle APIs for the same transaction signature.
  • If the signature belongs to a bundle, it requests bundle details and extracts the landed tip amount.
  • If no bundle is found, it treats the transaction as Normal.

Why these fields matter together

A standard transaction page usually tells you what executed. The Node1 plugin focuses on giving more visibility into how that transaction landed. Used together, the three rows help answer questions like:

  • Did this transaction land under the leader I expected?
  • Did the slot transition change right before landing?
  • Was Jito involved?
  • What tip was visible on the Jito side?
  • Which client type was running on that leader mapping?
  • Which region and validator label were associated with the landing context?

Who this plugin is for

The plugin is intended for users who care about transaction landing visibility rather than only transaction result visibility. Typical use cases include:

  • Traders checking how specific transactions landed.
  • Bot developers debugging execution and routing behavior.
  • Infra users tracking leader and provider context.
  • Researchers comparing landing patterns across validators, regions, or providers.

This is especially useful when you are looking at many Solscan transaction pages and want the extra routing context directly on-page instead of cross-checking several external tools manually.

What the plugin does not claim

  • It does not submit transactions.
  • It does not improve latency by itself.
  • It does not guarantee landing quality.
  • It does not replace RPC, relays, or private transaction infrastructure.

Its purpose is observation and interpretation. It helps you inspect a transaction page with more context than Solscan shows by default.

How to use it

Source code and installation guide on GitHub: Node1-Git/checktx-node1

  1. Install the extension in Chrome.
  2. Open a Solscan transaction page.
  3. Read the three injected rows: Landed By, Prev Leader, and Provider.
  4. Use the copy buttons when you need the current or previous leader pubkey for further analysis.

Summary

The main value of the Node1 Solscan Plugin is not that it adds more text to a transaction page. The useful part is the structure of that text.

Landed By shows the leader that matches the landing slot. Prev Leader shows what came right before. Provider shows whether Jito bundle landing appears to be involved and what tip was paid when available.

That combination turns a standard Solscan transaction page into a more useful landing-analysis view.