Repository navigation
fix: tolerate burn-induced mint supply drift below pool records (v0.1.4) - #5
Merged
Merged
Conversation
Every v0.1.3 pay run on sol3 failed with "pool mint authority, supply, decimals, or freeze state mismatch". Live mainnet forensics showed exactly one failing condition: validate_pool_mint required the vSOL mint supply to equal the stake pool's recorded pool_token_supply, but direct burns pull the mint supply below the pool's records between epoch updates (85 base units at the time of diagnosis). The on-chain program tolerates this and re-syncs pool_token_supply from the mint at each epoch's UpdateStakePoolBalance, and deposit math uses pool_token_supply on both sides, so the drift is harmless. Keep the direction that is genuinely suspicious: a mint supply above the pool's records would mean tokens minted outside pool accounting and still fails. Add a regression test on verbatim mainnet mint bytes with drifted pool supply, and include actual values in the mint and stake-pool guard errors so the next failure is diagnosable from the journal alone. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Root cause (from live evidence, not guesswork)
Every v0.1.3
payrun on sol3 fails withpool mint authority, supply, decimals, or freeze state mismatch(Loki,vsol-payment.service, 2026-08-27 02:00 and 07:34 CEST). Checking each condition ofvalidate_pool_mintagainst live mainnet, exactly one fails: the strictsupply == pool.pool_token_supplyequality. The real vSOL mint supply was 85 base units below the pool's recorded supply — direct burns drift the mint down between epoch updates. The SPL stake pool program tolerates this and re-syncspool_token_supplyfrom the mint at each epoch'sUpdateStakePoolBalance, which is also why the check passed on some runs (fresh after re-sync) and failed on others.All other assumptions were verified clean against mainnet: invoice PDAs and 96-byte layout, invoicer layout and reserves ATA, payer funding, stake pool decode, withdraw-authority-as-mint-authority.
Changes
validate_pool_mint: allowsupply <= pool_token_supply(burn drift); still bail when supply exceeds pool records, which would mean minting outside pool accounting.bail!named no values.tests/fixtures/mainnet_vsol_mint.bin) with burn-drifted pool supply, plus a supply-above-records rejection test.Note: this branch is based on v0.1.3 (
le/fix-simulation-commitment), which was tagged but never merged — merging this lands the whole chain onmain.Verification
cargo fmt --check,clippy -D warnings, 47/47 tests pass.planmode was run against live mainnet with sol3's production values — it passes every validation and plans payment of the real outstanding epoch-1021 invoice (46,882,974 vSOL base units, 55,061,062 lamports deposit), exit 0.