Solana vs Sui block explorers

TLDR

Solana and Sui are both high-throughput non-EVM chains, but they take very different approaches to state, parallelism, and addressing. Solana uses base58 addresses and an account model; Sui uses 0x-prefixed hex addresses and an object-centric model. tx.taxi routes Solana lookups to Solscan and Sui lookups to SuiVision.

Address & transaction format

Solana addresses are 32-byte Ed25519 public keys encoded in base58. They are typically 32 to 44 characters long, contain no 0x prefix, and use a restricted alphabet that omits 0, O, I, and l to reduce visual ambiguity. Solana transaction identifiers are base58-encoded signatures, usually 87 or 88 characters. Slot numbers (Solana's block-height analogue) are integers, and block hashes are base58 strings.

Sui addresses are 32 bytes shown as 0x followed by 64 hex characters, 66 characters in total. This makes Sui addresses superficially similar to Ethereum transaction hashes (both 0x and 66 characters), but in Sui that string identifies an address, not a tx. Sui transaction digests are also 32 bytes, but they are typically displayed in base58 rather than hex, so a Sui tx digest looks similar to a Solana signature in shape (base58, no 0x), though it tends to be shorter (around 44 characters in base58).

Object IDs on Sui are also 32-byte values in the same 0x-prefixed hex form as addresses, because Sui treats addresses and objects under a unified type. Checkpoint numbers (Sui's coarse-grained ordering primitive) are integers; checkpoint digests are 32-byte hashes.

The most reliable structural tells: a base58 string with no 0x is either Solana (long, 32-88 chars) or possibly a Sui tx digest (shorter, around 44 chars). A 0x-prefixed 66-character hex string with no chain context is most likely a Sui address or object ID, or an EVM tx hash. The 0x prefix is never used for Solana identifiers.

Block explorers tx.taxi uses

For Solana, tx.taxi's primary configured explorer is Solscan. Solscan is a well-known Solana explorer covering account state, SPL token holdings, transaction instructions across many programs, and validator data.

For Sui, tx.taxi's primary configured explorer is SuiVision. SuiVision is a widely-used Sui explorer covering accounts, objects, transactions, packages (Sui's term for deployed Move modules), and checkpoint data.

Both explorers expose chain-native concepts. Solscan shows compute units and program instructions; SuiVision shows gas budget, object mutations, and Move call breakdowns. Neither maps cleanly onto an EVM-style transaction page, which is part of why a chain-aware explorer matters.

When to use which

If your value is base58 with no 0x prefix, it is most likely Solana-shaped and routes to the Solana chain page, then to Solscan. If your value is 0x-prefixed and 66 characters long, it could be a Sui address or object ID; the Sui chain page routes to SuiVision. Sui transaction digests in base58 are shorter than Solana signatures, but this can be ambiguous, so context matters.

In practice you usually know which chain you are dealing with from how you got the value (a Solana wallet shows Solana things, a Sui wallet shows Sui things). tx.taxi handles the routing automatically when you paste at tx.taxi/{value}.

See EVM vs Solana addresses for the addressing primer and what is a block explorer for the explorer basics.

Common confusions

The first confusion is the object model itself. Solana has accounts: every piece of state is stored under an account, owned by a program. Sui has objects: every piece of state is an addressable object with its own ID, owner, and version. A Sui "NFT" is an object you own; a Solana "NFT" is an SPL token account with metadata referencing it. The explorers reflect this. SuiVision lists the objects under an address; Solscan lists token accounts. The mental model you bring from one will mislead you on the other.

The second confusion is transaction identification. Solana transactions are signed by potentially many keys and identified by one of those signatures. Sui transactions have a single digest that hashes the transaction content. Both chains support transactions that touch many pieces of state in parallel, but Sui's object-versioning model makes the parallelism explicit (an object has a version, and a transaction touching it advances the version), while Solana's account locks happen at a different layer.

The third confusion is the hex prefix collision. Because Sui uses 0x-prefixed hex addresses and digests can also be hex in some contexts, users sometimes paste Sui values into EVM explorers (which silently fail to resolve) or assume Sui is an EVM chain. It is not. Sui uses the Move execution model, not the EVM. tx.taxi disambiguates by length and chain context rather than by prefix alone, so you do not need to worry about this when routing.