Since the launch of Atlas V1 on December 15th 2025, and the V2 on January 6th, the Atlas Explorer (FLP explorer) and Lunar Explorer (ao mainnet) are the only 2 visualisations that uses the data Atlas processes and provides. In this blog post we will show how Atlas API can be used beyond explorer-style data queries and visualizations: how to build FLP-gated applications.

[i] the Forward Research team is working on a potential performance change from daily-mints schedules to real-time streaming. A radical update that would make the creation of FLP-gated applications even more reliable and accurate, with more conditional-gating shuffled options to have.

Revisiting Atlas

For new readers, Atlas is software built by the DLL team to provide easily queryable ao-adjacent data. Atlas V1 was focused on FLPs, indexing the community FLPs delegation and emission data, the ao pre-bridge LST oracles, and making relational data queries easy for the first time without forcing users to dive into the rabbithole of message-linking to calculate their desired data.

Atlas V2 came out recently with more extensive data indexing, focused on indexing ao mainnet (ao.N.1) messages.

Atlas runs on a self-hosted ClickHouse cluster using the ReplacingMergeTree engine, which makes full mainnet message indexing both fast and inexpensive. It can comfortably handle hundreds of thousands of rows per second on modest hardware, which is enough to index every ao.N.1 message in real time without batching or lag. And on the query side, typical block-range or tag-filtered queries scan millions of rows in milliseconds, even as historical data grows.

Atlas is the developer-friendly, API swiss army knife to query ao-related datasets. Check the Atlas source code here.

Building an FLP-gated Faucet

Beyond explorers and massive queries, Atlas can be used to determine whether any given address is delegating to a fair launch project -- useful for building gated applications and incentivizing delegation.

The article’s gating application is based on something we built internally for the upcoming Load Network Fibernet release: a $LOAD FLP-delegation gated faucet.

In our case, we have a single input for the conditional faucet tokens release, the user’s EVM address (EOA). How can we resolve the user’s FLP delegation preference from the EOA? The solution is in simple 2 steps.

Step 1: resolving the EOA

To resolve the AR/AO address linked to the pre-bridge EOA address (LSTs staker), we have to use the Atlas /wallet/identity/eoa/{eoa} handle.

Taking this LOAD staker profile, found easily on atlas.decent.land, we have the EOA: 0x2a01d339d3ab41b2d8b145b5df8586032d9961c6

The way that Atlas Explorer knows how to handle the AR <> EOA address identity links is through Atlas API reverse resolving.

Now back to our project, we have a way to easily get the associated AR addresses of a given EOA, from the pre-bridge delegation oracle data on ao.

Step 2: Getting the user’s delegation preference

Now that we have the AR address associated with the user’s EOA, the next step is to fetch its FLPs delegation preferences. In our app, we need only the latest delegation preference:

curl https://atlas-server.decent.land/wallet/delegations/kaYP9bJtpqON8Kyy3RbqnqdtDBDUsPTQTNUCvZtKiFI

Response:

{
  "_key": "base_kaYP9bJtpqON8Kyy3RbqnqdtDBDUsPTQTNUCvZtKiFI",
  "delegationMsgId": "CZXZN4_R8OXUOOL838oH4PnSodDPM7X08PiM98C6YKc",
  "delegationPrefs": [
    {
      "factor": 5000,
      "walletTo": "kaYP9bJtpqON8Kyy3RbqnqdtDBDUsPTQTNUCvZtKiFI"
    },
    {
      "factor": 5000,
      "walletTo": "Qz3n2P-EiWNoWsvk7gKLtrV9ChvSXQ5HJPgPklWEgQ0"
    }
  ],
  "lastUpdate": 1764337794203,
  "totalFactor": 10000,
  "wallet": "kaYP9bJtpqON8Kyy3RbqnqdtDBDUsPTQTNUCvZtKiFI"
}

We can see that the user’s AR wallet address has set 50% (5000) delegation preference to LOAD FLP (Qz3n2P-EiWNoWsvk7gKLtrV9ChvSXQ5HJPgPklWEgQ0) as last update. If we want more complex features for our app, for example, over-time weighted faucet payout based on historical delegation preferences, we can use this mappings endpoint:

https://atlas-server.decent.land/wallet/delegation-mappings/kaYP9bJtpqON8Kyy3RbqnqdtDBDUsPTQTNUCvZtKiFI

This returns the full history of the wallet’s Set-Delegation actions.

Glueing it all together

Now that we have all the API pieces together, we can finally build our $LOAD delegations FLP-gated faucet for Fibernet. In this blog post we wont go in details on how to hook a REST API with a UI and add you intermediate custom logic (claude it :D) - so here’s a sneak peek:

Your delegation-gated application can have a wide range of conditions, for example:

  • Is the user delegating more than x% to my FLP?
  • Is the user delegating an average greater than x% to my FLP over y days?
  • Is the user delegating an LST i prefer for my FLP (USDS/stETH/DAI)?
  • Is the user delegating at least xxx USD to my FLP?

Wrapping it up

Today we learnt how we can build a FLP-delegation-preference gated application using the Atlas REST API. This conditional-gating concept is useful for SoFi, creator economy dApps, noise-filtering, DAO forums, and other applications where economic stake overlap with the community of an FLP.