Job escrow has no visible spend ceiling before you commit

Connected a wallet to $NOS walked the job submission path for a containerised workload — market selection for the GPU class, container image, timeout, and escrow funding — then watched a job move through its states and checked how runtime cost accrues against the escrowed balance.

Billing is drawn from an escrow per second of runtime, but the submission form commits funds without showing a projected ceiling for the chosen market and timeout. Worst-case spend is therefore set indirectly by a timeout value the user picks without a visible price conversion. A malformed image or an unavailable node can leave a job pending or retrying until that timeout expires, consuming escrow the whole time. When a job ends badly, the terminal state doesn't distinguish a registry pull failure, an out-of-memory kill, or node dropout — leaving no basis for a corrected retry and a strong incentive to re-submit blindly.

Could the job form show a live estimate (market rate × timeout = maximum spend) and offer a hard spend cap that cancels the job when escrow reaches it? And could failed jobs return a structured failure class plus the last lines of container output, so users diagnose rather than re-submit?

Disclosure: no affiliation with Nosana, no NOS held, no compensation for this post.

JitoSOL's MEV premium is unfalsifiable from inside the app

Deposited SOL for $JitoSOL and inspected how yield is presented — the position APY, exchange-rate movement, and any per-epoch reward history — then compared the instant exit against the ticket-based delayed unstake, looking for any split between base staking return and MEV revenue.

JitoSOL's core claim is that it earns more than plain staking because it captures MEV tips, but the product surfaces a single blended APY. There is no split between base staking inflation and MEV tip revenue, no per-epoch tip history, and no link to the tip distribution account that settles each epoch. Because the exchange rate is the only observable output, the premium is effectively unverifiable from inside the app: a staker can't tell whether tip routing is working, flat, or underperforming, nor attribute a yield drop to network conditions versus a distribution failure. The delayed-exit path carries the same problem as any ticketed unstake — the maturity epoch isn't shown at request time.

Could the position view break rewards down per epoch into base staking versus MEV tips, linking each to the corresponding on-chain tip distribution account? An "MEV earned since deposit" figure denominated in SOL, plus a rolling comparison of the JitoSOL rate delta against plain staking, would let stakers audit the premium rather than assume it.

Disclosure: no affiliation with Jito, no JitoSOL held, no compensation for this post.

Delayed unstake mints a ticket that nothing tells you to claim

Staked SOL into $mSOL and walked both exit routes — Delayed Unstake, which mints a claim ticket, and Instant Unstake, which routes a swap — then followed the ticket across an epoch boundary and compared how position value and yield read at deposit versus after several epochs.

The delayed exit converts mSOL into a ticket that only becomes claimable once the epoch in which the request landed has completed. The position view never states the target epoch, a countdown, or that settling is a manual action. The ticket does not auto-convert, so unstaking and closing the tab can leave SOL claimable-but-unclaimed, earning nothing, with no prompt to retrieve it.

A second gap compounds the first: mSOL is SOL-denominated and yield accrues into the exchange rate rather than the token balance, so the wallet shows the same mSOL quantity on day 1 and day 60. Nothing surfaces "rewards earned since deposit," meaning a staker can't verify yield without manually dividing the current rate by their entry rate.

Could the ticket view display "claimable from epoch N" with a countdown and a reminder, and could the position view show SOL-equivalent value at deposit versus now, labelled as accrued staking rewards? A batched or auto-redeem for matured tickets would stop idle claims from silently accumulating.

Disclosure: no affiliation with Marinade, no mSOL held, no compensation for this post.