fix(b20): announce scheduled splits via updateUIMultiplier - #88
Merged
Conversation
Publishing an announcement with a scheduled asset split always failed
with "We could not prepare this announcement for your wallet: Execution
reverted for an unknown reason."
assetAbi declared setUIMultiplier(uint256,uint256) (0x93d32890). The
Vibenet deployment implements updateUIMultiplier(uint256,uint256)
(0x628e600f). B20 tokens are native contracts there — eth_getCode
returns the 1-byte 0xef marker — so there is no source or generated
binding to catch the mismatch. The wrong name encodes into valid
calldata, announce forwards it as an internal call, the unknown selector
reverts, and the outer error carries no reason string.
Only the split path was affected: a plain announcement sends
announce([], ...) and never hits the bad selector.
cancelScheduledMultiplier() was dead the same way; the deployment
implements cancelUIMultiplierUpdate(). Nothing calls it yet, but it was
wrong in the exported ABI.
Verified against Vibenet by deploying an asset token and publishing a
2:1 split: estimateGas passes and the log bracket reads Announcement ->
UIMultiplierUpdated{prev 1e18, next 2e18} -> EndAnnouncement, with
effectiveAt() returning the scheduled timestamp. Argument order is
(multiplier, effectiveAt): a zero multiplier reverts 0x6f12f3dc and a
past timestamp reverts 0x14119cf6.
Swept every function in the demo's five ABIs against the live chain;
these two were the only dead selectors out of 34. The new test pins the
Asset selectors so a rename fails in CI instead of at the wallet.
Collaborator
🟡 Heimdall Review Status
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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.
Problem
Publishing an announcement with a scheduled asset split always failed:
Root cause
assetAbideclaredsetUIMultiplier(uint256,uint256)(selector0x93d32890). The Vibenet deployment implementsupdateUIMultiplier(uint256,uint256)(selector0x628e600f).B20 tokens are native contracts on Vibenet —
eth_getCodereturns the 1-byte0xefmarker — so there is no Solidity source or generated binding to catch a mistyped function name. The wrong name encodes into perfectly valid calldata,announceforwards it as an internal call, the unknown selector reverts, and the outer error carries no reason string. Hence the opaque message.Only the split path was affected. A plain announcement sends
announce([], …)and never hits the bad selector, which is why that button worked.cancelScheduledMultiplier()was dead the same way; the deployment implementscancelUIMultiplierUpdate(). Nothing calls it yet, but it was wrong in the exported ABI.Changes
protocol.ts—setUIMultiplier→updateUIMultiplier, with named args to pin the orderprotocol.ts—cancelScheduledMultiplier→cancelUIMultiplierUpdateAnnouncementModule.tsx— updated the call siteprotocol.test.ts— pins all sixassetAbiselectors to the values read off the live deployment, so a rename fails in CI instead of at the walletVerification
Deployed an asset token on Vibenet and published a 2:1 split through the same encoding path as
submit():announce([<multiplier call>], …)0xb288a127announce([], …)The successful transaction emits the full bracket —
Announcement→UIMultiplierUpdated{prev: 1e18, next: 2e18, effectiveAt: 2026-08-26T14:31:34Z}→EndAnnouncement— andeffectiveAt()then returns the scheduled timestamp.Argument order confirmed as
(multiplier, effectiveAt): a zero first arg reverts0x6f12f3dc, a past-timestamp second arg reverts0x14119cf6.I also swept every function in the demo's five ABIs (
b20Abi,assetAbi,factoryAbi,policyRegistryAbi,activationAbi) against the live chain. These two were the only dead selectors out of 34.npm run typecheck,npm test(134 passing), andnpm run lintare clean on this branch.Not covered: I did not exercise this through the browser UI, since the operator path needs a connected wallet holding
OPERATOR_ROLE. The verification above drives the identical encoding path, but the click-through is unconfirmed.