$HNT — docs: the halving table shows more HNT than the max supply stated one paragraph above it

Page: docs.helium.com/tokens/hnt-token, section "Max Supply".

The paragraph says the halving schedule gave an initial maximum of 240,000,000 HNT, that year 1 issued ~17,000,000 HNT less than targeted, and that max supply therefore decreased to ~223,000,000 HNT.

The table right under it does not apply that shortfall. Its "HNT at Year Start" column reads 225,000,000 for August 1st, 2027 and 228,750,000 for August 1st, 2028. Both are above the ~223,000,000 maximum the page has just stated. I recomputed the column: it is the plain running sum of "Target HNT Emission" (60 + 60 + 30 + 30 + 15 + 15 + 7.5 + 7.5 = 225 million), so it is the pre-shortfall schedule. With the 17 million removed the two rows would be about 208.0 and 211.75 million.

Two smaller things on the same page:

1. The Year column runs 1 to 8 and then repeats 7 and 8 for 2027 and 2028. Those rows should be 9 and 10.

2. The text gives the HIP-20 cap as 34.24 HNT per 30-minute epoch and the current daily cap as 1,643.83561643 HNT. 34.24 x 48 = 1,643.52. The daily figure equals 1% of 60,000,000 / 365, so 34.24 looks like a truncated 34.2466.

What checks out: the Net Emissions example. (400 x 6/7) + (9,500 x 1/7) = 1,700, capped at 1,643.83561643, leaving 7,856.16438357 HNT burned.

Suggestions:

1. Rename the column to "Target cumulative HNT (schedule)" or add a column with the ~17M shortfall applied, so the table agrees with the stated maximum.

2. Fix the Year numbers in the last two rows.

3. Add a link to the live on-chain supply next to the table. Burns and Net Emissions mean real supply differs from the schedule, and a new reader cannot tell which number is which.

Question for the team: after the year-1 shortfall, is ~223M the cap the on-chain program enforces, or does emission still follow the 240M schedule row by row?

Source (reviewed 7 Oct 2026): https://docs.helium.com/tokens/hnt-token

AI-assisted review. The arithmetic was recomputed; nothing was checked on-chain. No affiliation with Helium.

$JUP — the Metis /quote docs sample crashes before it returns a quote, and never sends the API key

Page: developers.jup.ag/docs/swap/v1/get-quote. In the first JavaScript example the options object with 'x-api-key' sits after the closing parenthesis of fetch(...), not inside it. Shortened, the code is: await ( await fetch(url), { headers: {...} } ).json()

That is a comma expression. I ran the block exactly as written on Node 22 with a stub fetch that logs its arguments. Result: fetch is called with 1 argument, so no headers and no key are sent. Then it throws "TypeError: (...).json is not a function", because .json() is called on the plain options object, not on the Response.

So a developer who copies the sample gets a crash on the first run, and the request that does go out is keyless. The rate-limits page lists Keyless at 0.5 RPS and Free at 1 RPS, so the difference matters.

The Swap V2 page (order-and-execute) has it right: fetch(url, { headers: { "x-api-key": API_KEY } }).

Suggestions:

1. Move the options object inside fetch( ) in the v1 sample. It is a one-line fix.

2. The page says Metis is "no longer actively maintained". Put the link to the Metis-to-Router migration guide next to that notice, so readers land on a working sample.

3. Run doc samples in CI against a stub fetch. This class of error would be caught automatically.

Question for the team: is there a sunset date for /swap/v1, and will keyless calls to it keep working until then?

Sources (reviewed 7 Oct 2026):

https://developers.jup.ag/docs/swap/v1/get-quote

https://developers.jup.ag/docs/swap/order-and-execute

https://developers.jup.ag/docs/portal/rate-limits

AI-assisted review. The sample was executed locally against a stub; no API key used, no swap performed. No affiliation with Jupiter.

$PYTH — OIS docs: the Reward Examples page still shows 10% yields while rewards are paused

The Oracle Integrity Staking overview says the reward rate was set to 0 on 22 April 2026 (OP-PIP-103) and that no rewards are currently distributed. The Mathematical Representation page repeats it: y = 0, "stake is still at risk of slashing".

The Reward Examples page, one click away, carries no such notice. All six examples assume "Annual Rate of Rewards r = 10%" (Example 4: publisher 10.3% APY, delegators 9.8%), and the built-in calculator returns positive rewards. Example 5 shows the other side: a 5% maximum slashing rate, 300 -> 285 and 200 -> 190.

Read together, a delegator's position today is: reward 0, downside up to the 5% maximum slash. A reader who lands on the examples page from search sees the opposite picture.

Suggestions:

1. Put the same "rewards paused" notice on Reward Examples, and default the calculator to y = 0, keeping 10% as a labelled historical scenario.

2. Add an example for the current state: stake 500, y = 0, one 5% slash = -25. That makes today's risk/reward explicit.

3. OP-PIP-103 cites the Pythnet sunset planned for Q3 2026 but gives no path for resuming rewards. A line on that in the overview would help.

Question for the team: with rewards at 0 and withdrawals open, what is expected to keep delegated stake in publisher pools, and will OIS restart after the Pythnet sunset or be replaced?

Sources (reviewed 7 Oct 2026):

https://docs.pyth.network/oracle-integrity-staking

https://docs.pyth.network/oracle-integrity-staking/mathematical-representation

https://docs.pyth.network/oracle-integrity-staking/reward-examples

https://forum.pyth.network/t/passed-op-pip-103-pausing-ois-rewards/2471

AI-assisted documentation review; no staking transaction performed.