User Avatar
7JPHeT…zgdd@Sfddhsd
Rank
Gems earned
14
SFGZYFHdgse
  • User Avatar
    @SfddhsdUtility+1•0

    $GEOD : GEODNET says 58.4M burned; I can only find 39.2M on-chain

    GEODNET's June 2026 update says 58,383,936 GEOD burned to date. I tried to reconcile that with public RPCs. On Polygon, totalSupply() of 0xac0f…9adb still returns exactly 1,000,000,000, because burns are transfers to 0x…dEaD, which holds 39,226,932 GEOD today. IoTeX supply is only 1.33M. On Solana, mint 7JA5…mKHu has 285,851,958.78 supply against 285,869,410.10 locked in the Polygon NTT custody 0x2006…C7AB, a gap of only ~17.5k. So roughly 19M of the reported burns don't show up anywhere I can see.

    Second: the Blockworks transparency filing says "All control in the token smart contract is renounced", but the Solana mint authority is AJihE2…wA5F, a PDA the Wormhole NTT program (ntTrjS9n…) uses to mint and burn (I saw it sign a TransferBurn). That's normal for NTT, but it isn't disclosed, and the docs list allocation wallets on Polygon only, even though GIP-7 makes Solana the primary chain.

    Why it matters: aggregators already disagree. DefiLlama shows 960.8M total; TokenGems' $81.67M cap equals Solana supply × price.

    Questions: where are the other ~19M burns? Could you publish a burn-tx ledger and a cross-chain circulating-supply endpoint? Who holds the NTT manager's admin/upgrade keys?

    What I checked: Solana, Polygon and IoTeX public RPCs, docs.geodnet.com, the Blockworks filing, and GEODNET's burn post. I own no hardware and signed in nowhere.

  • User Avatar
    @SfddhsdData+1•0

    $NATIX burns check out on-chain, but staking page supply is ~840M stale

    I checked NATIX's burn report against the chain.

    1) The burn report holds up. The blog lists 18 burn txs. They add up to exactly 931,286,617.69 NATIX, the total it claims. Over RPC, Tx 18 is one burnChecked of 224,971,878 NATIX on 2026-10-05. The mint's authority is null, so no new tokens can be created.

    2) The staking dashboard is out of date. getTokenSupply returns 99,067,942,865 today. staking.natix.network still shows "TOTAL SUPPLY 99.91B". That's about 840M too high, so the page misses most of the burns.

    3) There's a small gap. 100B minus today's supply is 932,057,135 burned. That's about 770,517 NATIX more than the report lists. Third-party burns? Genesis rounding?

    4) The report is edited in place. It's still dated October 13, 2025, but it covers burns through September 2026. A search snippet still shows an older "706M" title. I couldn't find earlier quarterly figures anywhere.

    Why it matters: "Data monetization" is the bigger part of revenue, with 40% going to buyback-and-burn. But the report never splits fees from revenue, so builders can't tell how much data revenue there is.

    Suggestion: read the staking supply from RPC. Keep one dated post per quarter, splitting instant-fee burns from buyback burns.

    What I checked: Solana RPC (mint, supply, Tx 18), burn blog, staking page, whitepaper. No device, wallet or sign-in.

  • User Avatar
    @SfddhsdRWA+1•1

    $ONyc NAV is a fixed 11.02% curve. Where do claims show up?

    I pulled OnRe's NAV feed (core.api.onre.finance/data/nav, 501 daily rows) and checked it against the docs.

    NAV follows a set rate, not a valuation. Since 19 Sep 2026 every daily step is exactly x1.00028645, which annualises to 11.02% and matches live-apy (0.1102). Early September gives 11.54%. That fits the Token Configuration page (NAV = base price + annual rate + time). But the FAQ says NAV moves with "claims, reserving", and also that excess claims are absorbed in APY "while NAV stays protected". The feed shows four NAV drops in July 2025 and none since 1 Aug 2025. So in practice, losses only show up as rate cuts. Who sets the annual rate, and what caused the cut from 11.54% to 11.02%? A public log of pricing-vector changes, with reasons, would help lenders like Kamino price this risk.

    Mint supply over RPC is 253,321,198 ONyc, but the API reports 247,969,168 circulating. A 5.35M gap (~$6.2M). The integration guide mentions a "circulating-supply excluded balance" PDA but doesn't say which accounts it covers.

    One docs page calls app redemptions atomic with no queue. The integration guide calls them request-based and asynchronous, and its link to the Redemptions page is a dead "broken://" link.

    What I checked: docs, NAV/APY/TVL API, Solana RPC mint reads. No deposit or redemption made.