hawkfi: TVL frozen 196 days, backend.hawksight.co is NXDOMAIN (protocol still active, $372k/30d fees)

[tarun-khatri]

projects/hawksight/index.js fetches TVL from https://backend.hawksight.co/portfolio/total_yield. That host no longer exists, so the adapter throws and DefiLlama has been carrying forward a stale value since 2026-01-06 — 196 days.

The data source is gone

$ nslookup backend.hawksight.co
*** can't find backend.hawksight.co: Non-existent domain

$ curl https://backend.hawksight.co/portfolio/total_yield
HTTP 000   (host does not resolve)

It is NXDOMAIN, not a timeout or a 5xx.

The protocol is very much alive

This is a dead feed, not a dead protocol, so deadFrom would be the wrong call:

• HawkFi's automation signer HAWK3BVnwptKRFYfVoVGhBc2TYxpyG9jmAbkHeW9tyKE submitted 5 successful transactions on 2026-07-20 at 12:21:55 UTC, invoking the Meteora DLMM program LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo and HawkFi's own program FqGg2Y1FNxMiGd51Q6UETixQWkF5fB92MysbYogRJb3P.
• The fees adapter (fees/hawkfi.ts, Allium-based, independent of the dead host) is reporting normally: $372,337 over 30 days, $6,439 in the last 24h.

So the site currently shows a 196-day-old $8,059,794 TVL for a protocol that is actively rebalancing liquidity today.

No drop-in replacement endpoint

The project rebranded Hawksight → HawkFi, and I could not find a public replacement:

host	result
backend.hawksight.co	NXDOMAIN
backend.hawkfi.ag, api.hawkfi.ag	do not resolve
backend.hawkfi.io, api.hawkfi.io	do not resolve
hawksight.co/portfolio/total_yield	307 → www.hawksight.co/... → 404 (marketing site)
hawkfi.ag	alive (Vercel) but rate-limits unauthenticated requests; no documented public TVL route

This adapter was previously repaired the same way in #16658, when api.hawksight.co/data/hawksight_tvl died and was swapped for the current host. That option isn't available this time.

Why I'm filing this rather than sending a PR

The correct fix is to compute TVL on-chain from HawkFi's Meteora DLMM and Orca Whirlpool positions. I did not want to guess at that: positions appear to be held per-user rather than under one enumerable owner, so identifying the HawkFi-managed set means reverse-engineering the account layout of program FqGg2Y1F... and/or deriving the managed set from what the automation signer touches. That is a substantial rewrite with real room to get the number wrong, and I would rather not ship a TVL figure I cannot fully stand behind.

Happy to implement it if a maintainer can confirm the intended approach — or if someone from HawkFi can point at a current public endpoint, the fix becomes a one-line change.

[tarun-khatri]

I went further on whether the TVL can be reconstructed on-chain, since that would be the proper fix. It can't, and I think the reason is worth recording so nobody repeats the work.

The repo already has everything needed to value a Meteora position. projects/helper/utils/solana/layouts/meteora-dlmm-layout.js decodes PositionV2 / LbPair / BinArray, and projects/unicrypt-solana/meteora-dlmm.js implements the valuation (walk bins lowerBinId..upperBinId, amountX += share * bin.amountX / bin.liquiditySupply, then api.add(tokenXMint, amountX)). So the arithmetic isn't the problem. The problem is enumerating which positions are HawkFi's.

1. The positions aren't tagged as HawkFi's. PositionV2 has an operator field (offset 7960), which is what an automation service would set. On every position touched by HawkFi's automation signer HAWK3BVnwptKRFYfVoVGhBc2TYxpyG9jmAbkHeW9tyKE, it is the null system program:

HpYgJrDrvkuQtNaJDAcE1P9BCZguCqx5UDoQtEpEuAqf  owner=ALTpJDgsqJhAdtEeyZQekf7jUyH9kJh8RyUzoYbizivC  operator=1111...1111
C4yyRv6nkcT5xYEr6mcPGgjMoPuNR53cyFqtgrQpbFxE  owner=8trJNHFQjVQ3dN5yUpveDM4SxxV4d67hvsun1Lko88Hh  operator=1111...1111
DfNys6EGbJuT3NeNE7Va4gEk2GX5pQ2hH9aH8wHdWA37  owner=5P3jhaN8w6Fcj1328LqCJYQ8Rj9KWNTdxH23feJTEzkf  operator=1111...1111
D9encoWBjJg1TtGpBDnSMjX9mmFWrho1HQMmBVk31mrY  owner=6mYLkJeQxNRF6Br9oYaHFCEq4czxJe4aAwwfNENAEQWZ  operator=1111...1111

Four distinct end-user owners, no operator. There is no memcmp filter that selects HawkFi's positions out of every other Meteora position.

2. HawkFi's own program state doesn't reference live positions. getProgramAccounts on FqGg2Y1FNxMiGd51Q6UETixQWkF5fB92MysbYogRJb3P returns 24,584 accounts, 24,567 of them a single 752-byte type (discriminator 9011f207136bad76). I scanned those records for a pointer to a live position at every byte offset, not just aligned ones — 333 distinct 32-byte windows across 4 records:

live accounts: 5    Meteora DLMM-owned: 0    Orca Whirlpool-owned: 0

The pubkeys they hold are user wallets and already-closed accounts (positions are closed and reopened on rebalance).

3. Deriving the set from activity is not tractable for a daily adapter. Sampling 1,000 consecutive signatures from the automation signer:

1,000 signatures spanned 661 seconds  =  1.51 tx/sec  =  130,711 tx/day
30 days  ~  3,921,331 transactions
        ~  3,921 getSignaturesForAddress calls just to LIST them, before fetching a single body

Why this differs from the DLMM vault adapters already in the repo. sectorone-dlmm-vaults and metropolis-exchange-dlmm-vaults work because those are custodial vaults with a factory — getNumberOfVaults/getVaultAt enumerates them and the funds sit in vault contracts. HawkFi is non-custodial automation: users keep ownership of their own positions and HawkFi only rebalances them. Which positions are "HawkFi's" is a business relationship, not an on-chain fact — which is exactly why it lived in the backend that is now NXDOMAIN.

So the options are a restored endpoint, or an on-chain marker (setting operator on managed positions would make this a small adapter). If either appears, the implementation is straightforward and I'm happy to write it.

[0xshubhs]

Still reproduces, and the gap has widened since you filed. Refreshing the numbers in case it helps whoever picks this up:

• last TVL point is still 2026-01-06 at $8,059,794 — now 218 days stale (it was ~196 when you filed)
• last 30 stored points hold 1 distinct value, so nothing is moving at all
• backend.hawksight.co still does not resolve (getent hosts returns nothing), so the source has not come back

The protocol is unambiguously still alive, which is what makes the frozen figure a problem rather than a dead listing — fees are flowing today:

window	fees
24h	$4,672
7d	$38,070
30d	$226,560

So DefiLlama is currently showing $8.06M of TVL sourced from a January snapshot for a protocol that is actively earning.

I have not tried to reconstruct it on-chain — your note that it cannot be rebuilt from Solana state stands as far as I can tell, and I did not want to re-litigate that. Just flagging that the stale figure is still being served, in case that changes the calculus on whether the listing should carry a stale-data marker or be dropped until a source exists.

[mujtabasaqib]

Following up on the analysis above checking the position's plain owner field (not
operator, not feeOwner -- both confirmed unset on HawkFi-touched positions) against
4 positions known to be touched by HawkFi's automation signer:

ALTpJDgsqJhAdtEeyZQekf7jUyH9kJh8RyUzoYbizivC  -> owner program: FqGg2Y1FNxMiGd51Q6UETixQWkF5fB92MysbYogRJb3P (752 bytes)
8trJNHFQjVQ3dN5yUpveDM4SxxV4d67hvsun1Lko88Hh  -> owner program: FqGg2Y1FNxMiGd51Q6UETixQWkF5fB92MysbYogRJb3P (752 bytes)
5P3jhaN8w6Fcj1328LqCJYQ8Rj9KWNTdxH23feJTEzkf  -> owner program: FqGg2Y1FNxMiGd51Q6UETixQWkF5fB92MysbYogRJb3P (752 bytes)
6mYLkJeQxNRF6Br9oYaHFCEq4czxJe4aAwwfNENAEQWZ  -> owner program: FqGg2Y1FNxMiGd51Q6UETixQWkF5fB92MysbYogRJb3P (752 bytes)

So what looks like 4 distinct end-user owners, no operators points to 4 PDAs
controlled by HawkFi's own program, not user wallets. Checked in the other direction
too: bulk-scanning all live Meteora PositionV2 accounts and cross-referencing owner
against the full set of ~24.7k HawkFi PDAs matched ~1,550 live positions.

Not filing a PR yet, because the resulting TVL for the adapter doesn't hold up. With this
enumeration wired into the existing bin-walking valuation logic, I get ~$331k as TVL. But
30-day fees are running ~$184k, which does not look plausible. Which leads to enumeration above catching a relationship but still undercounting live positions somewhere -- possibly a position type outside plain PositionV2, or a gap somewhere else. Ruled out Orca Whirlpool as the cause for now: no activity from the automation signer on Orca's program in recent transactions, despite it being listed as a secondary integration in the fees adapter's comment.