This release includes breaking changes for platform teams planning a safe upgrade.
✓ No known CVEs patched in this version
Topics
Affected surfaces
Summary
AI summaryFix: Setup confirmation now re‑reads approvals post‑transaction to accurately report granted status.
Full changelog
Setup's approval report now shows the post-transaction chain state, not the
pre-transaction snapshot. Found live: a setup confirm:true that successfully
granted 4 approvals returned every one of them as granted:false.
fix(polymarket)— setup re-reads approvals after the batch lands. Both
modes (deposit-wallet batch and per-tx EOA) built their report from the
approvals snapshot taken BEFORE signing, then flippedapprovalsPendingto
false without a single re-read. So the response contradicted itself
(approvalsPending:false+granted:false), and the inverse failure — a
batch tx that lands but leaves an approval missing — was reported as success.
Same 0.32.6 principle, applied to setup: a transaction landing proves it was
mined, not that it did anything.verifyApprovalsLandedre-reads on-chain
(3 attempts, 750ms, matching redeem's post-transaction reads) and only a
fresh read showing every approval granted counts; an empty read can never
fake success, andapprovalsDoneis persisted only after verification. When
the tx landed but the chain doesn't confirm, the report says so explicitly
(approvalsUnverified:true+ a ⚠️ line) instead of ✅.structurednow carriesapprovalsTxHash(deposit-wallet) /
approvalTxHashes(EOA), so callers can link the batch without parsing text.- 223 tests, typecheck and build green.
Weekly OSS security release digest.
The CVE patches and breaking changes that affected production tools this week. One email, every Sunday.
No spam, unsubscribe anytime.
Share this release
About blockrunai/blockrun-mcp
Live data for AI agents — search, research, markets, crypto, X/Twitter. Pay-per-call via x402 micropayments.
Related context
Beta — feedback welcome: [email protected]