The XELIS block explorer — what you can (and can't) see

What you can see on a XELIS explorer

• Blocks — height, hash, timestamp, miner address, included transactions, and confirmation depth.
• Transactions — transaction ID, block inclusion, fee paid (in XEL), and validity proof status.
• Network state — current height, difficulty, hashrate, supply already issued.
• Address existence — that an address is a valid XELIS address.

What stays private

XELIS encrypts the meaningful bits. The explorer does not reveal:

• Account balances — every balance is encrypted using homomorphic encryption.
• Transaction amounts — confidential transactions hide the value moved.
• Sender or receiver wallet — stealth-style addressing breaks the link between on-chain entries and your real receiving address.

This means a XELIS explorer is great for confirming "did my transaction land?" and useless for "let me check this person's wealth" — which is exactly the point. The cryptography behind it is covered in the XELIS Wallet privacy features.

How to check a XEL transaction

1. Open XELIS Wallet and find the transaction in your history.
2. Copy the transaction ID (TX hash).
3. Paste it into the search bar of the official explorer.
4. Confirm the block height and confirmation count look correct.

Verifying you're on the real explorer

Explorer vs your wallet

Only your XELIS Wallet (with your view key) can decrypt your own balance and amounts. The explorer sees the same ciphertext everyone else does — it just confirms the chain is valid. That asymmetry is the privacy guarantee.

Reading a XELIS block, field by field

When you click into a block on the explorer, you'll see a dense screen of metadata. Most of it is operational telemetry — useful for miners, node operators, and the curious. Here's what each section actually means in plain language.

• Height is the block's position in the chain, counting up from the genesis block at zero. On XELIS's BlockDAG, height alone doesn't fully order blocks — sibling blocks at the same height are reconciled by topological ordering — but height is still the right field to quote when you say "the chain is at block N".
• Block hash is the unique fingerprint of the block's header. Two valid blocks can never share a hash. Use the hash, not the height, when you need to reference a specific block unambiguously across forks.
• Timestamp is the moment the miner claimed the block was produced. It's bounded by network consensus rules but not millisecond-accurate — treat it as good to within a minute, not a stopwatch.
• Miner is the address that received the block reward. This address is public because mining rewards are not confidential transactions — that's a deliberate trade-off so anyone can audit the issuance schedule.
• Difficulty / cumulative weight reflects how much work went into producing the block and how heavily later blocks have confirmed it. Higher cumulative weight on later blocks is what makes your transaction irreversible.
• Transactions is the list of TX IDs included in the block. Each entry includes the fee paid (in XEL) and the validity-proof status, but not the amounts, senders, or receivers — those remain encrypted.

How the explorer verifies a transaction without seeing inside it

This is the part that confuses newcomers: how can the network confirm a transaction is valid if it can't see the amounts? The answer is zero-knowledge proofs. Each XELIS transaction carries a cryptographic proof that the sender had enough balance, that the inputs and outputs sum correctly, and that no value was created or destroyed — without revealing what any of those numbers actually are.

The explorer (and every full node) verifies these proofs the moment the transaction lands. If the proof is valid, the block is accepted and the transaction is included. If it isn't, the block is rejected and a fork forms around the honest chain. From the outside, you see "Transaction confirmed in block N" — the proof verification happens silently underneath. This is the same property that makes the privacy guarantee meaningful: confidentiality is not the absence of verification, it is verification without disclosure.

What an analytics firm can and can't infer

Chain-analytics companies have built lucrative businesses on transparent blockchains by tracing the graph of public transactions, clustering addresses likely controlled by the same entity, and selling that data to exchanges, governments, and lenders. None of that works on XELIS, because the graph they would trace doesn't exist on-chain — amounts are encrypted, account state is encrypted, and there is no transparent input/output history to cluster.

What they can see is metadata: that a transaction happened, what time it landed, which node first relayed it (if they run their own observation infrastructure on the peer-to-peer layer), and the fee it paid. None of this links to your real-world identity unless you've separately leaked that link — by reusing an address you previously posted publicly, broadcasting from your home IP without a VPN, or KYC-ing on an exchange that handled the same XEL. The privacy properties XELIS gives you are powerful, but they only protect what you don't separately reveal.

Self-hosting the explorer for maximum privacy

Every public explorer is a trusted observation point — whoever runs it sees every query against it. For most users that's fine; for some, it isn't. If you want zero third-party visibility into which transactions or addresses you look up, the XELIS explorer is open-source and can be run locally against your own node. The full stack (daemon + explorer + web UI) runs comfortably on a small VPS or a home machine with a few gigabytes of disk and modest RAM. Once it's running, you query http://localhost instead of a remote URL, and no-one but you knows what you searched for.