As an increasing number of DeFi protocols deploy on Sui, Shared Objects have become essential components of liquidity pools, lending markets, and other on-chain financial applications. However, a seemingly simple permission issue can expose an entire protocol's risk parameters to unauthorized calls.

Suppose a Sui lending protocol stores its liquidation threshold inside a shared Market object. Regular users need to access this Market object to make deposits, borrows, and repayments, while administrators are responsible for adjusting risk configurations like collateral ratios and liquidation thresholds.

Now, what happens if a regular user can modify the liquidation threshold through a public function?

An attacker might not need to compromise an administrator account or bypass Move VM security mechanisms. They only need to find a state-modification path lacking proper authorization checks to alter critical protocol parameters, directly impacting the liquidation conditions of existing positions.

This represents a key class of issues worth studying in Sui Shared Object Security.

Sui Move provides strong foundational security guarantees through Object Ownership, resource models, and type systems. However, these mechanisms do not automatically determine whether every business operation aligns with a protocol’s intended permission design.

For DeFi protocols containing multiple Pools, Vaults, and Markets, developers must manage even more complex object relationships, Capability scopes, and state transition rules.

In MoveBit's (a flagship sub-brand of BitsLab) Sui security research, access control for Shared Objects is a critical direction during security audits. This article uses a simplified lending market case study to analyze how missing access checks create vulnerabilities, what issues can arise in Capability design, and how to verify these risks through testing and security audits.

1. Why Do Shared Objects Require Dedicated Access Control Considerations?

Sui utilizes an Object Model to manage on-chain state. Every object possesses a unique identifier, ownership metadata, and versioning. Protocols choose different object ownership models based on operational needs.

Common ownership forms include Address-Owned Objects, Immutable Objects, and Shared Objects.

  • Address-Owned Objects: Transaction usage rights are constrained by explicit object ownership.
  • Immutable Objects: Can be publicly read by anyone but cannot be modified.
  • Shared Objects: Allow different users to concurrently reference the same object within transactions and execute operations defined by the Move contract logic governing that object.

Sui's official documentation explicitly states that any address can submit a transaction referencing a Shared Object; therefore, when privileged operations are involved, the contract itself must execute the corresponding authorization checks.

For DeFi applications, shared access brings clear operational value.

For example, an AMM protocol can use a Shared Object to store liquidity pool reserves, fee configurations, and protocol parameters. Different users can execute transaction functions to interact with the exact same Pool.

LiquidityPool
├── Token A Reserve
├── Token B Reserve
├── Trading Fee
└── Protocol Configuration

When regular users perform a swap, asset balances within the pool are updated according to protocol rules. However, modifying trading fees, updating pause states, or altering key configurations usually constitute restricted operations.

While both types of operations may utilize &mut LiquidityPool, the authorization requirements they must satisfy are fundamentally different.

In Sui Move, &mut T allows a function to modify data of type T, provided it satisfies type and borrowing rules. It does not natively provide admin authentication, nor does it confer arbitrary capabilities upon the caller to modify object fields. Which specific modifications can be executed remains entirely dictated by the module defining the object type and its public functions.

Consequently, security analysis of Shared Objects must look deep into function implementations and authorization relationships between objects.

2. What Risks Does an Access-Control-Deficient Market Function Present?

Consider a simplified Sui lending market where the protocol utilizes a shared Market object to store liquidation thresholds and other risk parameters:


Under normal conditions, regular users access Market to perform borrowing and lending operations, while liquidation_threshold should only be modifiable by authorized administrators or governance mechanisms.

Suppose a developer implements the following function:


This code successfully passes basic type checks and indeed modifies the Market's liquidation threshold.

The critical issue is that this function contains no authorization checks whatsoever.

A public function can be accessed via permitted cross-module calls or Programmable Transaction Block (PTB) invocation paths. If a shared Market can be passed as a transaction input, an attacker can supply a mutable reference to the shared Market along with an arbitrary new_threshold.

No Move resource safety rules are violated here. The attacker simply uses a legitimately referenced shared object to execute a publicly exposed protocol operation.

Assuming the liquidation threshold uses basis points with an initial value of 8,000 (80%), if an attacker modifies it to 9,900 or another abnormal value, the market's liquidation conditions will diverge completely from the original design.

The exact consequences depend on the protocol's parameter validation ranges, health factor calculation methods, and liquidation execution logic. Certain implementations could render high-risk positions temporarily unliquidatable, while others might cause healthy positions to suffer abnormal liquidations.

For this specific example, the confirmed flaw is clear: an unauthorized user can modify critical risk parameters that should have been strictly protected.

Whether actual financial losses occur depends on further analysis of the protocol's business logic and economic parameters.

3. How to Reproduce and Verify This Attack Path

When conducting a security analysis on this example, auditors can start with the liquidation_threshold field:

  1. Confirm where it is initialized.
  2. Determine which functions read its value.
  3. Check if alternative modification paths exist.
  4. Inspect the visibility and parameters of writing functions to verify if regular users can construct the required object inputs.

For the update_threshold() function shown above, the potential execution path is direct:

Attacker Transaction
        ↓
Shared Market Object
        ↓
Public update_threshold()
        ↓
No Authorization Check
        ↓
liquidation_threshold Modified

Throughout this invocation flow, the function does not request an AdminCap, nor does it verify caller identity or any authorization conditions.

To further verify the vulnerability, developers can use Sui's official test_scenario framework to simulate different transaction senders.

For instance, Account A creates the Market and sets it as a Shared Object. Then, the test switches to Account B (which lacks administrative permissions), and Account B attempts to modify the liquidation threshold via the public function.

The following code demonstrates the key testing logic:


Code Note: This test is for instructional purposes, assuming create_market() is already implemented in the test package and correctly creates a Shared Market. It demonstrates the vulnerability verification concept and has not been independently compiled.

In actual testing, if an unauthorized account successfully executes the call and the Market's liquidation threshold is altered upon transaction completion, the unauthorized state modification path is proven to exist.

Next, auditors must evaluate whether this parameter change impacts borrowing limits, position health, or liquidation outcomes. Only by completing business-level validations can the severity and exploitability of the vulnerability be accurately gauged.

In complex protocols, attack paths might span multiple public functions and modules. For instance, a function might not directly modify the liquidation threshold, but could achieve the same result by updating configuration objects, swapping dependent objects, or invoking functions in other modules.

Therefore, security audits must trace the complete State Transition path to ensure every path capable of modifying sensitive state is protected by proper authorization.

4. How to Fix Access Control Issues Using the Capability Pattern

Sui Move typically manages privileged operations using the Capability Pattern.

A Capability is an object that represents permission to execute a specific operation. Functions restrict sensitive operations by requiring callers to provide a reference to a specific Capability object.

For our lending market example, we can create an AdminCap corresponding to each Market, storing the target Market's ID inside the Capability itself.

Below is a simplified remediation implementation:


Code Note: This example demonstrates object-level authorization core implementation and excludes real lending, liquidation, governance, or permission revocation modules. create_market() is designed to allow users to create independent demo markets and does not imply production lending protocols should adopt permissionless market creation. This code has not been independently compiled.

Compared to the vulnerable version, the updated update_threshold() function introduces three critical constraints:

  1. Requires &AdminCap: When the Capability employs proper Address-Owned ownership, Sui's object ownership model restricts who can pass it as a transaction input.
  2. Validates Market Binding: admin.market_id == object::id(market) verifies the explicit link between the Capability and the Market. Even if a caller possesses a valid AdminCap, they cannot use it to modify a different Market.
  3. Validates Bounds & Emits Events: Checks the bounds of new_threshold and emits a ThresholdUpdated event upon success to facilitate off-chain tracking of parameter changes.

Crucial Requirement: During remediation, legacy public functions lacking permission checks must be removed or restricted. Retaining legacy entry points allows attackers to continue modifying fields through unprotected paths.

Key Considerations for Capability Design

1. Ownership of the Capability Itself

Suppose a protocol mistakenly sets an AdminCap as a Shared Object. If any user can pass references to this shared Capability into privileged functions, the requirement for &AdminCap fails to enforce admin access controls.

A Capability's effectiveness depends entirely on its type, ownership model, and usage restrictions enforced within contract logic. Permissions meant for a single administrator or governance body must use controlled ownership or vault structures to prevent unauthorized access.

2. Association Between Capability and Target Objects

In multi-market, multi-pool, or multi-vault protocols, verifying the Capability type alone is insufficient.

If Market A and Market B both accept the same AdminCap type without ID validation, a user holding management rights over Market A could illegally manage Market B. Binding market_id as shown in the example provides baseline protection against cross-object unauthorized calls.

Production protocols should also validate Capability versions, protocol instance IDs, permission roles, and governance states.

3. Creation, Transfer, and Revocation Lifecycle

Once created, a Capability becomes a critical asset within a protocol's privilege architecture.

Audits must confirm that Capabilities cannot be duplicated, misallocated, accidentally transferred, or retained after admin handovers.

When permissions are compromised, protocols must be capable of rejecting compromised Capabilities. Recommended Sui practices include:

  • Valid Capability ID registries
  • Version control
  • Epoch-based expiration checks

Relying solely on compromised holders to voluntarily destroy capabilities is insufficient for revocation.

Additionally, if a protocol supports upgrades, auditors must review UpgradeCap holders and upgrade policies. Even if current implementations enforce strict checks, future code upgrades could alter these rules.

Capability security must cover the complete lifecycle: Creation $\rightarrow$ Possession $\rightarrow$ Usage $\rightarrow$ Transfer $\rightarrow$ Revocation $\rightarrow$ Upgrade.

5. How to Verify That Fixes Are Effective

After introducing Capability checks, security tests must be updated accordingly:

  • Positive Validation: Authorized administrators can successfully modify their assigned Market.
  • Negative Validation: Unauthorized users fail when attempting the same operations.
  • Cross-Capability Testing: Multi-market protocols must test scenarios involving mismatched Capabilities (e.g., attempting to update Market A using Market B's AdminCap).

Under the updated logic, mismatched operations must fail due to Object ID validation errors. The core test assertion is:

assert!(
    admin.market_id == object::id(market),
    EWrongMarket
);

In unit tests, developers can use #[expected_failure] to confirm that EWrongMarket is raised as intended.

It is important to distinguish between two failure types:

  • Logic Failure: Supplying a valid Capability belonging to another Market triggers contract-internal assertion failures.
  • Ownership Failure: Failing to possess an Address-Owned AdminCap causes rejection during Sui transaction input validation before Move function execution starts.

Both failure types require testing, though their verification methods differ.

Additionally, development teams must audit all functions capable of writing to liquidation_threshold. If update_threshold() is secured but a public update_config() function still allows unrestricted modifications to the same field, the risk remains unresolved.

For production lending protocols, verification should span three levels:

  1. Permission Testing: Ensure every sensitive operation has explicit authorization checks, and test mismatched objects, cross-instance Capabilities, and alternative invocation paths.
  2. Parameter Constraint Testing: Validate that risk parameters (liquidation thresholds, fees, collateral ratios) can only be modified within strictly defined ranges.
  3. Protocol Behavior Testing: Verify that post-modification borrow, repayment, and liquidation operations adhere to expected economic constraints.

Sui's CLI tool supports running unit tests via sui move test, while test_scenario enables simulation of multi-sender transactions, object transfers, and shared object interactions:

sui move test

Prior to mainnet deployment, protocols should validate operations across local networks, Testnet, and real transaction constructs to ensure contract logic behaves as expected within the live Sui execution environment.

For production protocols, comprehensive confidence in remediation effectiveness requires code reviews, permission testing, and business logic verification working in unison across all critical state transitions.

6. How MoveBit Analyzes Permission Risks in Complex Sui Protocols

The previous example featured a single Market and one AdminCap, making attack paths straightforward to trace. However, real-world Sui DeFi protocols feature far more complex object topologies.

A lending market may simultaneously depend on Pool, Vault, Position, Oracle, Treasury, and Governance objects. Logic is distributed across multiple modules, with state managed dynamically via Dynamic Fields.

In these environments, simply checking if a function accepts an AdminCap parameter is insufficient to assess overall authorization security.

1. Starting from Object Relationships

MoveBit's Sui Smart Contract Audit builds state and authorization maps around a protocol's Object Model to identify:

  • Shared objects vs. private objects.
  • Objects holding critical assets or risk configurations.
  • Mappings between Capabilities and target objects.

For example, a lending liquidation process involves user Positions, shared Markets, Oracle prices, and liquidation parameters. Auditors verify that these objects belong to the expected protocol instance, check for cross-market object mixing, and ensure states cannot be modified through unauthorized calls.

2. Tracing Authorization Logic Along Execution Paths

The second step involves mapping all public functions capable of modifying sensitive fields alongside their invocation hierarchies.

For Market.liquidation_threshold, auditors identify every potential write path and evaluate its authorization controls. If a function relies on tx_context::sender(), auditors check whether business rules strictly require transaction-sender-based checks. Where permissions are represented via Capabilities, governance objects, or escrow patterns, auditors evaluate ownership conditions and authorization boundaries.

In protocols with extensive cross-module interactions, special focus is placed on ensuring permissions are not improperly forwarded, escalated, or reused.

3. Combining State Transition Analysis with Practical Verification

Final risk determinations rest on state modification outcomes:

  • Can an execution path successfully alter the liquidation threshold?
  • Does the modified parameter impact active positions?
  • Can an attacker leverage the modified state to execute unauthorized borrows, withdrawals, or liquidations?

Answering these questions requires analyzing code execution paths, object relationships, and business logic while verifying findings through concrete PoC tests.

For large-scale Move protocols with complex object relationships, AI-assisted analysis can provide valuable support.

BitsLab developed BitsLab AI, focusing on Logic Reasoning, Evidence Chains, and PoC Verification. It combines code logic understanding, risk path analysis, and vulnerability verification.

Starting from sensitive state fields, it traces related functions and permission checks, flags potential unauthorized modification paths, and uses automated testing to confirm exploitability.

This methodology helps auditors systematically organize suspicious paths and verification evidence. While AI provides analytical leads for complex cross-module and multi-object interactions, final conclusions must always be verified against Sui Object Ownership rules, Capability holding conditions, and Move VM execution mechanics.

MoveBit brings extensive security experience across the Sui ecosystem. In Sui's June 2025 ecosystem security review, "Greater Ecosystem Security Through Audits and Move Registry", MoveBit was recognized as a key security audit firm within the Sui ecosystem, with special mention of its contributions to formal verification, developer tooling, and security competitions.

MoveBit's public audit portfolio includes leading Sui ecosystem projects such as Scallop, Cetus, and NAVI Protocol. These public audit reports help development teams understand real-world audit scopes, code versions, issue classifications, and fix verification processes.

For complex Sui DeFi applications, security audits must evaluate object ownership, permission design, state transitions, and business rules within a unified execution context to accurately identify potential risks.

7. Shared Object Security Must Cover the Entire Protocol Lifecycle

Shared Object permission issues must be addressed before protocol deployment.

In lending, trading, and yield protocols, critical states undergo continuous evolution. Projects frequently add new Markets, adjust risk parameters, switch Oracles, or introduce new business modules via Package Upgrades.

These changes can alter existing authorization dynamics:

  • Does an AdminCap designed for a single market maintain appropriate permission boundaries as the protocol expands?
  • Do newly added configuration functions reuse legacy permission checks correctly?
  • Does a package upgrade introduce new invocation paths capable of modifying sensitive state?

Every upgrade impacting permissions or critical state requires thorough re-verification.

Sui's official security guidelines emphasize that smart contract audits must evaluate specific code versions, dependencies, and upgrade authorities. For upgradeable protocols, security guarantees from an earlier audit do not automatically extend to future code modifications.

Consequently, teams must establish continuous security review processes, complemented by traceable events and monitoring rules for parameter updates and admin operations.

Conclusion & Next Steps

For teams building or upgrading Sui DeFi protocols involving Shared Pools, Markets, Vaults, or complex Capability designs, conducting a comprehensive audit of object relationships, permission checks, and state transitions prior to deployment is highly recommended.

MoveBit provides specialized Smart Contract Security Audits for Sui and Move ecosystem projects, focusing on object ownership, permission logic, state transitions, and protocol business risks to help teams identify and remediate potential security flaws before mainnet deployment.

If your project is preparing for deployment, upgrading smart contracts, or re-evaluating audit requirements, reach out via the official MoveBit website to discuss your code scope, protocol architecture, and security review needs.

Related Resources

Sui Official Documentation

MoveBit Research & Audit Resources

BitsLab AI