[framework] Add native function to check protocol feature flags in Move

[lxfind]

Adds sui::protocol_config::is_feature_enabled() to allow Move code to query protocol feature flags at runtime. This enables conditional logic and fallbacks based on protocol version capabilities.

Description

Describe the changes or additions included in this PR.

Test plan

How did you test the new or updated feature?

---

Release notes

Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.

For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.

• [ ] Protocol:
• [ ] Nodes (Validators and Full nodes):
• [ ] gRPC:
• [ ] JSON-RPC:
• [ ] GraphQL:
• [ ] CLI:
• [ ] Rust SDK:
• [ ] Indexing Framework:

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
sui-docs	Ready	Preview	Comment	Dec 5, 2025 0:32am

2 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
multisig-toolkit	Ignored	Preview		Dec 5, 2025 0:32am
sui-kiosk	Ignored	Preview		Dec 5, 2025 0:32am

[lxfind]

I would like to gate object balance withdraw separately from address balance withdraw

[tnowacki]

I would like to gate object balance withdraw separately from address balance withdraw

But both of those bottom out in a native function? Why not just gate within the native like we are doing currently?

[tnowacki]

To be clear, I don't inherently dislike this PR by any means, it just seems like overkill unless we really need it. (and I'm surprised if we do since we haven't needed it for like 3 years)

[lxfind]

It's not though: https://github.com/MystenLabs/sui/blob/main/crates/sui-framework/packages/sui-framework/sources/funds_accumulator.move#L86

I heard from Mark that he has wanted this a few times, but since there are always walkarounds (some not so ideal) so this wasn't ever a big complaint.

[mystenmark]

To be clear, I don't inherently dislike this PR by any means, it just seems like overkill unless we really need it. (and I'm surprised if we do since we haven't needed it for like 3 years)

i think we've been adding a lot of stuff recently that could benefit from this. most recently we were contemplating adding a native to be called from withdraw_balance_from_object just so that we could gate that function separately. which is annoying because that native has to then live forever even though its private.

[mystenmark]

I think it would be safe to just invariant violation on unknown/invalid strings? But maybe there is something tricky going on with upgrades?

hmm, there is no way i know of to prevent unknown items from becoming known items after a binary upgrade but before a protocol upgrade. so we need to make sure that the behavior is identical for both unsupported and unknown items

[lxfind]

hmm, there is no way i know of to prevent unknown items from becoming known items after a binary upgrade but before a protocol upgrade. so we need to make sure that the behavior is identical for both unsupported and unknown items

That is true, but the only way for that to happen is someone shipped a framework upgrade that used a feature flag that isn't already present. I don't think this would happen since this is internal only, but I agree it's better to be safe.