SVM Scan: Building a More Powerful Explorer and Data Layer for the Steem Virtual Machine

blaze.apps (75)adminVerified Developerin SVM - EVM on STEEM • 5 days ago

Over the past few weeks, I have been spending quite a lot of time building around the Steem Virtual Machine (SVM) ecosystem.

One of the projects I have been working on is SVM Scan, an explorer and indexing platform for SVM.

When I initially started working on it, I used the excellent open-source Dexplorer project by arifintahu as the foundation. Dexplorer is designed as a lightweight Cosmos-based blockchain explorer, and it provided a useful starting point. (GitHub)

But as SVM continued to grow beyond a simple Cosmos SDK chain and into an ecosystem with EVM, DeFi, IBC, STEEM bridging, validators/oracles and SVM Name Service, I felt that a basic explorer was no longer enough.

So I started extending it.

And today, SVM Scan is becoming much more than the original explorer interface.

Introducing the SVM Scan Indexer

One of the biggest changes I have made is the addition of a dedicated Indexer + API backend.

Instead of relying entirely on querying the chain every time the frontend needs information, SVM Scan now has a background indexer that walks through the SVM blockchain block-by-block and stores structured information in MongoDB.

The indexer supports an initial backfill from the chain and then continues following new blocks in live mode. The API exposes this indexed information through a public REST interface. (blazeapps007.github.io)

This makes it possible to build much richer applications on top of SVM data.

The API is read-only, public and unauthenticated, meaning developers can directly consume the indexed data rather than having to build their own indexing infrastructure from scratch. (blazeapps007.github.io)

The API also provides consistent pagination, ISO-8601 timestamps and safe handling of large blockchain numbers.

You can explore the complete API documentation here:

SVM Scan API Documentation

Liquidity Pools

SVM is not just about moving STEEM around.

With the EVM layer, we are building toward an ecosystem where DEXs, liquidity pools, tokens and DeFi applications can operate directly on SVM.

SVM Scan now indexes Uniswap V3-style liquidity pool creation events from EVM transactions.

Each pool can expose information such as:

Pool address
Factory address
Token 0
Token 1
Token symbols and decimals
Fee tier
Tick spacing
Creation block
Creation transaction
Creation timestamp

The API currently identifies pools by processing PoolCreated events generated by EVM transactions. (blazeapps007.github.io)

You can explore the live liquidity pool section here:

SVM Scan — Liquidity Pools

This is particularly important for the growing SVM DeFi ecosystem, because explorers should not only show transactions — they should understand the protocols being built on top of the chain.

IBC Transfers

Another major part of SVM is Inter-Blockchain Communication (IBC).

SVM Scan now has a dedicated IBC transfer index.

The indexer detects transactions matching IBC packet-transfer patterns and records information including:

Sender
Receiver
Source channel
Destination channel
Source and destination ports
Amount
Denomination
Memo
Transaction hash
Block height
Timestamp
Transfer status

(blazeapps007.github.io)

This gives users a much easier way to understand what is actually happening when assets move between SVM and other IBC-connected networks.

SVM Scan — IBC Transfers

For me, this is an important part of making SVM feel like a connected blockchain ecosystem rather than an isolated chain.

SVM Bridge Tracking

Another area where I wanted much better visibility was the STEEM ↔ SVM bridge.

SVM Scan now indexes bridge deposits and withdrawals.

Steem → SVM

For deposits, SVM Scan can show information such as:

Steem transaction ID
Steem block
Steem sender
Gateway account
Amount
Memo
Derived SVM destination
Destination type
Deposit status
Mint status
Mint transaction
Creation height
Validator confirmations

The bridge deposit system records validator/oracle attestations, allowing users to see which validators have confirmed a deposit. (blazeapps007.github.io)

This is particularly useful because a bridge transaction is not simply a single transaction.

There is a process behind it.

STEEM transaction → bridge observation → validator/oracle confirmations → SVM mint

SVM Scan tries to make that entire process visible.

SVM Scan — Bridge Deposits & Withdrawals

Validator / Oracle Confirmations

This is one of the areas I am particularly happy with.

For bridge deposits, SVM Scan can show the validators/oracles that confirmed the deposit, including validator address, validator moniker and confirmation timestamp.

That means users can inspect not only:

"Was this deposit minted?"

but also:

"Who confirmed it?"

This provides an additional level of transparency around the bridge oracle process.

The underlying API exposes validator confirmation information as part of the bridge deposit record. (blazeapps007.github.io)

So a bridge transaction can now be understood at a much deeper level than simply looking at a transaction hash.

Bridge Withdrawals

The reverse direction is also indexed.

For SVM → Steem, the bridge records the burn transaction and withdrawal request.

SVM Scan exposes information such as:

SVM sender
Destination Steem account
Amount
Memo
Burn transaction hash
Withdrawal status
Creation height

(blazeapps007.github.io)

This creates a transparent record of the bridge-out lifecycle.

One important distinction is that the current implementation documents withdrawals as a queue for validators to relay manually on the Steem side rather than an automated Steem-side payout. (blazeapps007.github.io)

I think showing these details openly is important as the bridge infrastructure continues to mature.

SVM Name Service — Connecting Steem Users With SVM Addresses

Another feature I have been working on is SVMNS — Steem Virtual Machine Name Service.

Blockchain addresses are not exactly user-friendly.

Compare:

steem107662cdhfe760n2lk9yhsv8fdve3pkzhlmtsvu

with:

blaze.apps

The second one is obviously easier for humans to recognize.

SVMNS connects a Steem username with an SVM address through a registration lifecycle.

SVM Scan now allows users to search this relationship and inspect the history behind it. (blazeapps007.github.io)

The system supports:

Steem username → SVM address resolution
SVM address → linked Steem username lookup
Registration IDs
Link height
Full registration history
Pending registrations
Registrations awaiting confirmation
Active, superseded and expired registration states

(blazeapps007.github.io)

The really interesting part for me is the history.

Instead of only showing the current relationship, SVM Scan can expose the registration lifecycle and previous registrations associated with a Steem account.

SVM Scan — SVM Name Service

It Is Not Just an Explorer Anymore

This is probably the biggest change in my thinking about SVM Scan.

Initially, I was thinking:

"I need an explorer for SVM."

Now I am thinking:

"I need a data infrastructure layer for the SVM ecosystem."

There is a big difference between the two.

An explorer is something users visit to look up a transaction.

An indexer and API can become infrastructure that other applications use.

For example, the same indexed data can potentially power:

DeFi dashboards
Wallets
Bridge monitoring
DEX interfaces
Portfolio applications
Analytics platforms
Bots
Developer tools
SVM applications
SVMScan itself

The current API already exposes indexed blocks and transactions, account information, EVM data, ERC-20/NFT holdings, liquidity pools, IBC transfers, bridge data and SVM Name Service functionality. (blazeapps007.github.io)

That is the direction I want to take this project.

Open Source

Another important part of this project is that SVM Scan is completely open source.

I don't want the SVM ecosystem to depend on a closed explorer controlled by one person.

If developers want to inspect the code, improve it, build their own version, contribute features or use the API architecture as a reference, everything is available publicly.

SVM Scan — GitHub Repository

The API documentation is also publicly available:

SVM Scan API Documentation