Index Fun Order Book
Index.fun is a prediction market that lets user create and trade on indexes. This contest is focusing on robust testing of the newly created orderbook service that will be launched on Index.fun.
Details
Scope
On what chains are the smart contracts going to be deployed?
Sonic
If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?
We will use USDC as the primary currency for placing bets
We also use a forked conditional token standard (https://conditional-tokens.readthedocs.io/en/latest/developer-guide.html) for our outcome tokens - this is a version of ERC-1155.
Are there any limitations on values set by admins (or other roles) in the codebase, including restrictions on array lengths?
Owner/Admin Roles are TRUSTED with limitations:
VALUE RESTRICTIONS IN PLACE:
- Fee rates (feeRate, tradeFeeRate, userFeeRate): Maximum 10% (1000 basis points)
- Outcome count: 1-256 outcomes
- Resolution time: Must be future timestamp when set
- Batch claim operations: Maximum 50 claims per transaction
NO VALUE RESTRICTIONS (Admin fully trusted):
- All contract address updates (collateralToken, marketController, vault, etc.)
- Treasury address
- Oracle address
- Authorized matcher addresses
HARDCODED VALUES:
- MAX_FEE_RATE = 1000 (10%) - no plans to change
- Max batch claims = 50 - may increase if gas optimization needed
Are there any limitations on values set by admins (or other roles) in protocols you integrate with, including restrictions on array lengths?
No
Is the codebase expected to comply with any specific EIPs?
We use EIP-712 for signature validation in the Market Controller -> _verifyOrder
We use EIP-1155 for Conditional Tokens
We use EIP 1967 Upgradable Proxy
If there are issues violating “MUST” statements from these EIP, they can be considered Medium severity. The reports must show the impact that the non-compliance can lead to, besides just stating where the non-compliance is.
Are there any off-chain mechanisms involved in the protocol (e.g., keeper bots, arbitrage bots, etc.)? We assume these mechanisms will not misbehave, delay, or go offline unless otherwise specified.
Yes we use an off-chain orderbook system to efficiently matching user orders, we use a special role, authorizedMatchers to allow matching user orders
What properties/invariants do you want to hold even if breaking them has a low/unknown impact?
The number of tokens minted when creating conditional tokens must = vault collateral (for this specific token) * number of conditions
For example:
If there is 100 YES tokens and 100 NO tokens, the vault must contain $100
Equally, the number of YES tokens must exactly match the number of NO tokens
Please discuss any design choices you made.
IT Minting vs Token Swaps:
_executeTrade() intelligently detects if seller has inventory
If yes: direct token transfer (swap)
If no: JIT mints complementary positions
Please provide links to previous audits (if any) and all the known issues or acceptable risks.
N/A
Please list any relevant protocol resources.
Additional audit information.
We are using inspiration from Polymarket & open zeppelin conditional contracts to build the structure of this platform
Ensuring the logic of these is correct and the matching logic cannot be tampered with is vital for the success of the project so focusing of these elements will be the #1 priority
Total Rewards
Contest Pool
Lead Senior Watson
Lead Judge
14,800 USDC
5,500 USDC
2,100 USDC
Status
Scope
Start Time
End Time
Judging Rules
