Repository navigation
[CRITICAL] No upgrade coordination between contracts — independent upgrades break cross-contract ABI #170
Description
Activity
Hello,
I can work on this
Could you please assign it to me
Thank youGm gm boss. I would like to take this one on. I can add a contract_version() entry point to each of the four contracts, wire the governor's set_config to pin a coordinated version bundle, reject cross-contract calls when the version pinning doesn't match, and build the interface compatibility matrix stored in instance storage as the migration path across upgrades. Please assign it to me.
Hi team,
I'd like to work on resolving this issue. Here is my proposed plan of approach to establish version coordination and prevent ABI mismatches across independent contract upgrades:
Plan of Approach
-
Implement Contract Version Entry Points:
- Add a
contract_version() -> u32entry point to all four ecosystem contracts (prediction_market,pulse_token,referral_registry, andleaderboard).
- Add a
-
Governor Version Bundle Management:
- Extend the governor configuration (
set_config) to store a coordinated "version bundle" defining expected interface versions for each target contract. - Add validation logic during cross-contract interactions to verify that target contract versions match the pinned versions in the active version bundle.
- Extend the governor configuration (
-
Cross-Contract Version Checks & Rejection:
- Implement version assertions at the start of cross-contract call entry paths.
- Reject execution with a descriptive error (e.g.,
Error::VersionMismatch) if an uncoordinated upgrade leads to an invalid contract version pair.
-
Compatibility Matrix & Migration Path:
- Store an interface compatibility matrix in instance storage to allow non-breaking, backward-compatible interface updates across version transitions.
-
Testing & Validation:
- Write unit and integration tests simulating independent contract upgrades.
- Verify that matched version upgrades succeed smoothly while mismatched cross-contract calls fail explicitly at runtime before state modification.
I can implement these version check mechanisms and tests promptly.
-
- added a commit that references this issue
on Aug 30, 2026 🎉 This issue has been marked as completed on GrantFox!
@samjay8's PR #192 was approved and merged by @Muyideen-js.
🏆 @samjay8: You earned 40 FoxPoints for this contribution! Your current tier: Builder (2,180 total points). Track your full progress on GrantFox.
👏 Great work, @samjay8! Keep contributing to SPulse-Org.
- added a commit that references this issue
on Aug 31, 2026 - added a commit that references this issue
on Aug 31, 2026 - added a commit that references this issue
on Aug 31, 2026
Summary
The four contracts (prediction_market, pulse_token, referral_registry, leaderboard) can each be upgraded independently via their
upgrade()entry points. There is no cross-contract version check: a governor can upgrade one contract without upgrading the others, breaking the cross-contract ABI.Impact
prediction_marketexpects, but the market contract wasn't upgraded, the cross-contract call reverts or reads garbage.pulse_tokenchanges itsmintsignature, the leaderboard'srewardcall breaks.referral_registrychanges itsregister_referralreturn type,place_betfails mid-flow.Fix
interface_version()orcontract_version()entry point to every contract.set_configthat pins all four versions together.