SuiDeX Audit Contest : Program Info

SUIDEX is committed to security-first DeFi. We welcome the security research community to help us build the safest trading experience on Sui. Rewards up to $10,000 USDC will be distributed based on severity and impact of findings.

In scope

Target	Type	Severity	Reward
https://gitlab.com/test-sm/suidex_contract/-/tree/6b46c2da485e33e212b0320d311b73b46b542d9f Copy Copied	Smart Contract	Critical	Bounty

Target

https://gitlab.com/test-sm/suidex_contract/-/tree/6b46c2da485e33e212b0320d311b73b46b542d9f

Copied

TypeSmart Contract

Severity

Critical

RewardBounty

Focus Area

Program Details

Language: Sui Move
Network: Sui Mainnet/Testnet
Payment: USDC (rewards determined by severity and impact)

Key Risk Areas to Test

Critical/High Priority:

Arithmetic Overflow in fixed_point_math.move
Reentrancy in swap/farming operations
Access Control bypass in admin functions
Fund Loss scenarios in all contracts

Medium Priority:

Reward Precision loss in farm calculations
Epoch Management errors in token locker
Fee Distribution miscalculations

Low Priority:

Emergency Pause functionality
Input validation edge cases
Business logic inconsistencies

IN-SCOPE VULNERABILITIES

Critical

• Direct theft of any user funds (at-rest or in-motion) across any liquidity pair or supported Coin<T> type • Permanent freezing of user funds in pools, lockers, or farming contracts • Insolvency conditions where the protocol cannot fulfill user withdrawals • Theft or loss of claimable Victory rewards • Manipulation of the fee structure to redirect developer or LP rewards • Smart contract unable to operate due to lack of funds or broken state logic • Circumvention of access control modifiers (e.g., only_owner, only_admin, only_authority)

High

• Temporary freezing or locking of funds in liquidity and farm • Failure of reward distribution logic in Farms, VictoryLocker, or Router modules • Replay or reentrancy issues across trade, claim, and withdrawal flows • Price manipulation exploits impacting value returned from swaps, zaps, or LP removals • Gas griefing (e.g., unnecessary state growth, vec bloat, or overflow risks in per-user data) • Pool inflation or abuse of add_liquidity, or claim_and_lock functions

Medium

• Incorrect share calculations in LP tokens, staked positions, or reward weights • LP or staking position dilution under certain liquidity migration edge cases • Misuse of clock, timestamp, or outdated reference values in emissions or locking schedules • Math or logic errors in APR boost, reward decay, or locking mechanics

Low

• Unbounded gas usage (especially in claim_all and compound) • Missing checks that could result in unintended locking, burning, or reward denial • Logic bypass via invalid types, zero address abuse, or unchecked external calls • Architectural flaws, misnamed fields, or unsafe default behaviors

OU-OF-SCOPE VULNERABILITIES

These are explicitly excluded from reward eligibility under this audit competition: • Incorrect data supplied by third-party oracles (price or TWAP manipulation via upstream feeds) • Flash loan exploits that require unrealistic market conditions • Basic economic governance attacks (e.g., 51% vote control outside protocol logic) • Lack of protocol liquidity or low TVL-related UX failure • Sybil attacks • Centralization risk

Theoretical vulnerabilities without PoC (for Critical/High)

Code style and gas optimization suggestions
Sui framework vulnerabilities
Frontend/UI issues
MEV/front-running attacks (unless direct fund loss)
Test files and documentation
Already known issues documented in README
Issues requiring extensive social engineering

Program Rules

The following activities are prohibited by this contest event:

Any testing with mainnet or public testnet contracts; all testing should be done on private testnets
Any testing with pricing oracles or third party smart contracts
Attempting phishing or other social engineering attacks against employees and/or customers
Any denial of service attacks
Public disclosure of an unpatched vulnerability in an embargoed bounty
Make every effort not to damage or restrict the availability of products, services, or infrastructure
Avoid compromising any personal data, interruption, or degradation of any service
Localize all tests to your accounts
Perform testing only within the scope
In case you find chain vulnerabilities we’ll pay only for vulnerability with the highest severity.
Any details of found vulnerabilities must not be communicated to anyone who is not a HackenProof Team or an authorized employee of SuiDeX Company without appropriate permission

Discussion

We use Discord as official communication channel: https://discord.gg/XMCGNkGmBD Join the channel, and create #support ticket to be added for conversation.

Disclosure Guidelines

Do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization
No vulnerability disclosure, including partial is allowed for the moment.
Please do NOT publish/discuss bugs

Eligibility and Coordinated Disclosure

We are happy to thank everyone who submits valid reports which help us improve the security. However, only those that meet the following eligibility requirements may receive a monetary reward:

The vulnerability must be a qualifying vulnerability
Any vulnerability found must be reported no later than 24 hours after discovery and exclusively through hackenproof.com
You must send a clear textual description of the report along with steps to reproduce the issue, include attachments such as screenshots or proof of concept code as necessary.
You must not be a former or current employee of us or one of its contractor.
Provide detailed but to-the point reproduction steps

Rewards Distribution

50% for critical issues
30% for high issues
15% for medium issues
5% gas optimization issues, best practices Read more: https://docs.hackenproof.com/

Technical Resources

Required Finding Format

All submitted findings must follow the structure below to ensure clarity and consistency in the triage and evaluation process:

Overview: A brief summary of the issue, outlining the key risk or behavior observed
Description: A detailed explanation of the vulnerability, including relevant code snippets, affected contracts/functions, and reasoning behind the risk
POC / Validation Steps: Clear steps to reproduce or validate the issue. This can include transactions, test cases, or simulations
Recommendation: A specific and actionable fix or mitigation strategy. This section is required for all issues, regardless of severity.

Bug Report Submission Guidelines

Required Finding Format

All submitted findings must follow the structure below to ensure clarity and consistency in the triage and evaluation process:

Overview: A brief summary of the issue, outlining the key risk or behavior observed
Description:
- A detailed explanation of the vulnerability, including relevant code snippets, affected contracts/functions
- description of the impact (how much funds are at risk)
POC / Validation Steps (Mandatory): Clear steps to reproduce or validate the issue.
Recommendation (Mandatory):
- the recommendation must be provided as a code segment all issues that are missing any of these sections will be closed as invalid.

POC Example:

A. Complete Attack Test Case

#[test]
fun test_vulnerability_poc() {
    // Setup test environment
    let mut scenario = test_scenario::begin(@attacker);
    let ctx = test_scenario::ctx(&mut scenario);
    
    // 1. Initialize contracts
    let (factory, pair, farm, etc.) = setup_test_environment(&mut scenario);
    
    // 2. Setup vulnerable state
    // Add initial liquidity, create pools, etc.
    
    // 3. Execute attack
    let before_balance = get_attacker_balance();
    execute_exploit(&mut pair, attack_params);
    let after_balance = get_attacker_balance();
    
    // 4. Verify exploitation
    assert!(after_balance > before_balance + expected_profit);
    assert!(protocol_is_damaged());
    
    test_scenario::end(scenario);
}

#[test] 
fun test_vulnerability_fix() {
    // Same setup as POC
    let mut scenario = test_scenario::begin(@attacker);
    
    // Apply the proposed fix
    // Then run same attack - should fail
    let result = execute_exploit(&mut fixed_pair, attack_params);
    
    // Verify attack fails with fixed code
    assert!(result.is_err()); // Attack should be prevented
    
    test_scenario::end(scenario);
}

B. Step-by-Step Attack Instructions

# 1. Setup test environment
sui move test --filter vulnerability_poc

# 2. Analyze logs before fix
echo "Pre-fix attack results:"
sui move test --filter vulnerability_poc -v 2>&1 | grep "Balance\|Profit\|Exploit"

# 3. Apply fix and re-test
# [Include exact code changes needed]

# 4. Verify fix effectiveness
sui move test --filter vulnerability_fix -v

# 5. Log analysis commands
echo "Analyzing transaction logs:"
sui move test -v 2>&1 | grep -E "(ERROR|SUCCESS|BALANCE_CHANGE)"

C. Mathematical Proof (if applicable)

Initial State:
- Pool reserves: R0 = 1000, R1 = 1000
- K = R0 * R1 = 1,000,000

Attack Execution:
- Input: X tokens
- Expected output (honest): Y tokens
- Actual output (exploit): Y + ε tokens

Proof of Profit:
- Attacker profit: ε = [mathematical formula]
- Protocol loss: [formula showing fund drainage]
- Why attack succeeds: [mathematical explanation]

🎯 Areas of Interest for Improvement

We're looking for improvements to our dynamic emission calculation system. Current implementation works as designed, but we believe there may be opportunities for optimization in:

Calculation efficiency in weekly emission rate updates
Gas optimization for large-scale emission distributions
Edge case handling during phase transitions (bootstrap to post-bootstrap)
Precision improvements in decay rate calculations over 156-week period

Our current emission timing and allocation system is functional, but we welcome suggestions for enhancements in:

Synchronization accuracy between different reward pools
Allocation distribution across multiple lock periods simultaneously
State consistency during concurrent claim operations
Reward calculation precision across varying time periods

SuiDeX Audit Contest : Program info