$RAY Raydium's official documentation can make the cost of creating an AMM v4 or CPMM pool look significantly lower than the actual typical upfront SOL requirement.

The Protocol Fees page says:

“Creating a Standard AMM v4 or CPMM pool costs 0.15 SOL in pool creation fees.”

That 0.15 SOL is the protocol creation fee, not the full typical cost of creating the pool.

Raydium's own current fee-comparison documentation breaks the costs down as:

AMM v4:

~0.15 SOL rent

0.15 SOL creation fee

~0.30 SOL typical total

CPMM:

~0.04 SOL rent

0.15 SOL creation fee

~0.19 SOL typical total

The CPMM creation guide independently recommends having about 0.2 SOL available for pool creation rent, token-account creation and priority fees.

For AMM v4, reading “costs 0.15 SOL” as the required budget understates the typical upfront amount by approximately 0.15 SOL — roughly 100% relative to the stated figure.

For CPMM, the difference is approximately 0.04 SOL, or 26.7%.

Across 100 pool creations, those budgeting differences would correspond to roughly 15 SOL for AMM v4 or 4 SOL for CPMM.

The documentation is technically referring to “pool creation fees”, but using “costs 0.15 SOL” can easily be interpreted as the total creation cost.

Suggested fix:

“Raydium charges a 0.15 SOL protocol creation fee for Standard AMM v4 and CPMM pools, excluding Solana account rent and network costs.”

Then link directly to the total-cost comparison table.

Sources:
https://github.com/raydium-io/raydium-docs-v1/blob/main/ray/protocol-fees.mdx
https://github.com/raydium-io/raydium-docs-v1/blob/main/reference/fee-comparison.mdx
https://github.com/raydium-io/raydium-docs-v1/blob/main/user-flows/create-cpmm-pool.mdx

$mSOL I found a material inconsistency between two official Marinade documentation trees for mSOL delayed unstake. The current FAQ says delayed unstake takes 1 epoch (except the end-of-epoch window) and charges 0.2% / 20 bps. docs-beta.marinade.finance says Delayed Unstake is free / 0% and takes about 1-2 epochs. This is economically measurable: on 100 SOL the fee expectation differs by 0.2 SOL; on 1,000 SOL by 2 SOL, plus the timing expectation doubles at the upper end. I would redirect or clearly deprecate the beta page and keep one canonical fee/timing table. Main FAQ: https://docs.marinade.finance/marinade-protocol/faq Beta: https://docs-beta.marinade.finance/staking/liquid

$JUP I audited the official Jupiter CLI close flow and found a risk-control inconsistency. jup perps close exposes --slippage (default 200 bps), and single-position closes pass maxSlippageBps to positions/decrease. But the --position all branch calls postCloseAll(walletAddress), whose request contains only { walletAddress }, so an explicitly supplied slippage limit is silently omitted in close-all mode. Quantitatively, a user choosing 10 bps (0.10%) expects at most $10 of slippage tolerance on $10,000 notional; in close-all, that chosen 10 bps limit is absent from the request. I would either propagate maxSlippageBps through positions/close-all or reject/warn on --slippage with --position all. Evidence: https://github.com/jup-ag/cli/blob/main/src/commands/PerpsCommand.ts and https://github.com/jup-ag/cli/blob/main/src/clients/PerpsClient.ts

$NOS I found a reproducibility and supply-chain issue in Nosana's official Ollama example. The job downloads command.sh at runtime from raw.githubusercontent.com/KeesGeerligs/nosana/main/benchmarking/images/command.sh, makes it executable, and runs it immediately. Because it follows mutable main and no commit or checksum is pinned, the same ollama.json can execute different code over time without the job definition changing.

Suggestion: move the script to a Nosana-owned repo or image and pin an immutable commit or image digest. Better still, vendor the script into the container or verify a SHA-256 before execution. That would make the example reproducible and auditable.

Question: is the KeesGeerligs/nosana personal repo intended as a permanent production dependency, or is it leftover from benchmarking?

$NOS The official Endpoints tutorial has a reproducibility mismatch in its market selection. Step 2 posts the Ollama job to market 97G9NnvBDQ2WpKu6fasoMsAKmfj63C9rhysJnkeWodAf, but the sample CLI output directly below points to 7AtiXMSH6R1jjBxrcYjehCkkSF7zvYWte63gwEDBcGHq. Nosana's Quick Start explicitly calls 7Ati... "Market 3060", while the Stable Diffusion RTX 4090 example resolves the nvidia-4090 market to 97G9....

Because the market controls GPU class and NOS/s price, a reader can follow the command but see output for different hardware and cost assumptions.

Suggestion: regenerate the Endpoints sample output from the same 97G9... market and show a stable GPU label (RTX 4090 / RTX 3060) beside each market address.

Question: which market is intended for this tutorial today - 97G9... or 7Ati...?

$TUNA I found a reproducible fee-base contradiction in DefiTuna's official liquidation docs. The Liquidations page says the liquidation fee is 10% of "remaining funds after debt repayment," but its example starts with a $120 notional position and calculates 10% of $120 = $12 without subtracting any debt. Separately, the Fees page says the 10% liquidation fee is applied to the notional value, including unclaimed fees.

Those rules can produce very different outcomes. If a $120 position had $80 of debt, 10% of post-debt remaining funds would be $4, while 10% of notional is $123

Suggestion: define one canonical fee base and rewrite the example to show notional, debt repayment, fee base, liquidation fee, and user remainder in explicit order.

Question: is the intended liquidation fee 10% of notional, or 10% of post-debt remaining equity?

$JTO I compared Jito's official (Re)staking docs and found a fee mismatch that can change a user's exit-cost estimate. The (Re)staking Overview lists a 0.1% (10 bps) withdrawal fee under program fees, while the Withdrawal Guide says a standard withdrawal incurs both a 0.1% withdrawal fee and a 0.1% program fee - 0.2% total - before any additional vault-specific withdrawal fee. The Deposit Guide also says a 0.10% program fee applies on withdrawals.

On a 1,000-unit withdrawal, that is the difference between budgeting 1 unit and 2 units before vault-specific extras. Suggestion: use one canonical fee breakdown everywhere - program fee + vault withdrawal fee + any additional vault fee - and show a worked example with the current values.

Question: is 0.2% the intended standard baseline, or is the Withdrawal Guide double-counting one 10 bps fee?