Atlas is an explorer and data analytics framework for the AO fair launch, showing detailed breakdowns of bridge deposits, delegations, earnings, and the relationships between wallets and projects.

We built Atlas because we found it hard to track metrics around our Load Network fair launch.

The dashboard at ao.arweave.net shows daily project income and all-time earnings, but doesn't show:

  • Who is delegating
  • Which assets are being delegated
  • How delegation has changed over time
  • Current $ value of the bridged assets delegated
  • Which projects a given wallet are delegating to
  • The linked EVM addresses of any delegating Arweave wallet
  • offchain LST oracle data feed changes over time

With this data, we can map a clearer picture of the AO fair launch. We can see which projects are gaining momentum, when large delegation inflows occurred, and which wallets are 'superdelegators' (delegating capital to multiple projects).

Atlas has 4 major components: oracles, projects, wallets, and relationships.

In this post we'll explain the insight each gives and how we built the backend.

Oracle asset tracking

Atlas tracks all stETH, DAI, and USDS locked in the fair launch with a special indexing focus on the oracle’s LST assets staked to the tracked fair launches, with breakdowns by oracle and by project. The oracle feed histograms show delegation activity over time for each asset, and staking distribution charts highlight the top wallets by deposited amount.

This gives you a macro view of capital flows into the AO ecosystem and helps identify the largest stakeholders.

Note: Asset histogram indexing started on December 10th, 2025.

Project analytics

Atlas gives you a complete picture of every active fair launch project. Each project page shows the total value delegated across stETH, DAI, and USDS, with real-time dollar valuations. You can see exactly who is backing each project, how much they've delegated, and track the linked EVM addresses behind every Arweave wallet, including details of wallet linking history. For project teams and delegators, this transparency makes it easy to gauge community support and commitment.

The LST delegation history feature visualizes how delegation to each project has evolved cycle-by-cycle. This helps you spot trends: is a project gaining momentum? Are delegators pulling out? The historical view answers these questions at a glance, making it easier to understand which projects are building sustained traction versus those with more volatile histories.

Wallet profiles

Every wallet on Atlas has a profile page that aggregates delegation activity. You can see which projects a wallet supports, the percentage breakdown of their delegation, and the total dollar value they've committed. The profile also resolves ArNS and ENS names and displays linked EVM addresses, connecting the dots between Ethereum and Arweave identities.

The delegation history chart on each profile shows how a wallet's strategy has changed over time. This is particularly useful for identifying active participants in the fair launch, understanding delegation patterns, and seeing how wallets respond to market conditions or project developments.

The global search makes it possible to paste any Arweave or EVM address and find the assets they have deposited and projects they support.

Superdelegators & project relationships

The superdelegators table identifies wallets delegating capital to multiple projects. These are the power users of the fair launch -- well-informed holders who are spreading their stake across the ecosystem. Seeing which projects attract superdelegators can signal quality and legitimacy, as these users typically do deeper research before committing funds.

The project overlap heatmap visualizes which projects share common delegators. This reveals ecosystem clusters and helps you understand how delegators think about project categories or strategies. If two projects have high overlap, they might be competing for the same audience, serving complementary use cases, or hitting on a current trend.

How we built it

There is no clean-cut way to aggregate delegation data on the major AO explorers like ao.link and Lunar. Retrieving deposits, delegation events and weights means indexing all relevant EVM transactions and AO messages and transforming the data into a coherent timeline.

The Atlas backend consists of 5 crates: common, flp, indexer, server, and explorer. The core crate is the shared common while the others are self-descriptive. The crates that have no hard dependencies on the indexer can be imported into your Rust projects and reused with ease, such as the common and flp crates:

[dependencies]  
atlas-common = { package = "common", git = "https://github.com/loadnetwork/atlas" }  
atlas-flp = { package = "flp", git = "https://github.com/loadnetwork/atlas" }

Atlas' only hard dependency is Clickhouse for indexing, which can be easily linked to a self-hosted / local Clickhouse docker image or using clickhouse.com (only if you like overpaying for SaaS :D)

Our Atlas instance is hosted on baremetal, along with a local dockerized Clickhouse instance, and uses public Arweave gateways for GQL queries. Here’s an example .env.example:

CLICKHOUSE_URL=http://localhost:18123  
CLICKHOUSE_USER=default  
CLICKHOUSE_PASSWORD=changeme  
CLICKHOUSE_DATABASE=atlas_oracles  
ORACLE_REFRESH_SECS=600  
DELEGATION_CONCURRENCY=16  
ORACLE_TICKERS=usds,dai,steth  
SERVER_PORT=1212 # 12 titans :D

The “magic” behind Atlas is actually simply - we dived into how the fair launch projects work and push data (messages) to the ao network, from there, we joined the dots between its infra processes, messaging, the data pools on Arweave, and the offchain oracles that settles data (results) on ao.

Using this approach, Atlas data computation is lightweight, with no direct compute calls to ao processes, but reading its (processes) computation results from Arweave data pools. To learn more about the underlying data types, queries and logic, check out the common crate https://github.com/loadnetwork/atlas/tree/main/crates/common.

Using Atlas via REST API

Our Atlas hosted instance is available under atlas-server.decent.land with the indexer crate enabled allowing richer data feeds, and ultra-fast complex queries. At the time of writing, DLL’s Atlas V0 REST API is offered publicly unauth’d. Below are the list of REST GET methods you can use:

  • GET / – health info.
  • GET /wallet/delegations/{ar_address} – latest Set-Delegation payload for a wallet.
  • GET /wallet/delegation-mappings/{ar_address} - delegation preference history over Arweave blockheight, goes back to the start of _delegation process deployment.
  • GET /wallet/identity/eoa/{eoa} - returns the list of Arweave addresses associated with an EOA (bridge's identity linkage lookup)
  • GET /wallet/identity/ar-wallet/{ar_address} - reverse proxy of /eoa/{eoa}
  • GET /oracle/{ticker} – raw Set-Balances data payload for usds, dai, or steth oracles.
  • GET oracle/feed/{ticker} - returns the recent indexed oracle feeds -aggregated- with additional metadata
  • GET /flp/delegators/{pid} – merged snapshot of all tickers (LSTs + AR) delegating to a given FLP, including wallet/EVM mapping, factors, token amounts, and AR amounts.
  • GET /flp/delegators/multi?limit=100 - returns a list of delegators that delegate to at least 2 distinct FLPs.
  • GET /flp/minting/{project} - returns the latest FLP's cycle Own-Minting-Report data
  • GET /flp/metadata/all - return a vector of the tracked FLPs and their metadata
  • GET /flp/{project}/cycles?ticker={ticker}&limit={n} - returns the total delegated assets for the ticker's oracle (LST) cycle per project
  • GET /explorer/blocks?limit=100 - emits the last N indexed blocks.
  • GET /explorer/day?day=YYYY-MM-DD - per-block unique counts + summed-over-block totals for the given date (defaults to today).
  • GET /explorer/days?limit=N - same payload as /explorer/day, aggregated for the last N days (defaults to 7).

What’s next

Atlas V0, as a software, lib and dashboard, is an experimental release, focused solely on the data associated with the FLPs <> LST bridges. In the upcoming releases we want to fix any potential bugs (so please report to us if you find anything is off), introduce richer data feeds, ao network explorer backend, including LSTs yet non-FLP tracking to the system, AR delegation tracking, and data for the PI FLP. So please, we are looking for your feedback!

Give it a try at altas.decent.land