Look up an account once and read both halves of it. The explorer resolves an EVM address, a pax string, a did:layerx DID and a kernel account id to a single page, with one asset list and one merged activity feed. Every block, transaction and receipt carries a settlement rung of pending, instant, sealed or final, and the status answer names the rule and heights that decided it.

What it does

The explorer is a fork of Blockscout (backend v10.2.6, frontend v2.7.2) extended for Paxeer X. A transform inside the indexer's existing logs pipeline decodes LayerX kernel precompile logs into five new tables, so kernel activity lands in the same database as blocks, transactions and token transfers. On top of those tables it serves a joined account read that answers with one account's four identity spellings, one asset list and one activity feed, and a settlement ladder that reports how far any block, transaction or receipt has settled.

Key capabilities

• Joined account read at /api/v2/addresses/:hash/unified: four identity spellings, one asset list, one merged feed.
• Each asset carries a single total beside its chain, custody and kernel parts, in raw units.
• Settlement ladder of four rungs decided by one pure function: pending, instant, sealed, final.
• Per-transaction rung at /api/v2/transactions/:hash/status, with the anchor batches it was measured against.
• Anchor and receipt lists at /api/v2/paxeer-x/anchors, /receipts and /receipts/:id.
• A capability probe reports which kernel precompiles the connected node answers, refreshed every 30 seconds.

Differentiators

The joined read resolves the four spellings through the on-chain binding recorded in lx_account_bindings rather than an off-chain mapping, and drops reorged rows through the same consensus filter as token transfers. The ladder is one pure function every surface reads, and a height no source reports stays absent instead of standing in as a zero.

Outcomes

• Resolve one account's four identity spellings in a single lookup.
• See each asset's total beside its chain, custody and kernel parts.
• Check how far any block, transaction or receipt has settled.

Technical notes

• Backend needs Elixir 1.19.4-otp-27, PostgreSQL 16, ETHEREUM_JSONRPC_VARIANT=paxeer_x, CHAIN_ID, DATABASE_URL and a SECRET_KEY_BASE of at least 64 bytes; the three frontend routes are behind NEXT_PUBLIC_PAXEER_X_ENABLED=true.
• The five tables are lx_account_bindings, lx_custody_events, lx_anchors, lx_receipts and lx_market_events.
• lx_receipts is never filled by the log transform: a kernel receipt is not an EVM event, and the kernel history ingester that would fill it is not implemented.
• The kernel precompiles are not on the chain that is live now, so the capability probe reads them as absent and the surfaces built on them stay empty until that upgrade.
• Three precompile event families are decoded by no definition because no fixed column can hold them: AvailabilityAttested, the anchor guarantor and challenge events, and DepositRootRegistered.
• Two Node pins disagree inside the tree: the frontend requires >=22.14.0, the backend's asdf file pins 20.17.0. The explorer/ tree is GPL-3.0 and is not linked into the Apache-2.0 code. Database sizing notes assume 500k+ blocks per day, and range partitioning of logs and token_transfers is stated as not delivered.

More in Interface