Security Mechanisms

Security is critical in a decentralized marketplace. This contract implements several security checks to prevent unauthorized access and manipulation.

2.1 Ownership Checks

• Only the original offer owner can cancel a sell or buy order.

• Sellers must own the NFTs before listing them for sale.

2.2 Trade Validations

• Preventing invalid amounts:

  • Offers with 0 price or NFTs are rejected.

  • Users cannot overbuy or oversell assets.

• Currency Type Checks:

  • Buyers and sellers must use the correct token (CURRENCY).

  • Trade Ledgers only accept transactions in registered currencies.

2.3 Preventing Overflows

To prevent integer overflows, all calculations use safe arithmetic:

moveCopyEditfun safe_add(a: u64, b: u64): u64 {
    assert!(a <= MAX_U64 - b, E_OVERFLOW);
    a + b
}

This ensures that large trades don’t cause unexpected errors.

2.4 Deny List Enforcement

• If a collection enables deny lists, restricted users cannot trade.

• The deny list is managed by the collection owner.

---

3. Best Practices for Integration

To ensure smooth integration with this contract, follow these best practices:

3.1 Listening for Events

Marketplace applications should subscribe to blockchain events for real-time updates.

• Example: Track new orders using OfferCreated events.

• Example: Remove orders when OfferAccepted or OfferCancelled events are detected.

3.2 Validating User Inputs

Before calling contract functions:

• Ensure that users own the NFTs they want to sell.

• Verify that buyers have enough funds before accepting offers.

• Handle error codes gracefully in the frontend.

3.3 Batch Transactions for Efficiency

• Encourage batch processing of multiple buy/sell offers to reduce gas fees.

• Example: A buyer can purchase 10 NFTs in a single transaction using batch_accept_offers.

3.4 Price Indexing

• Use get_price_levels() to fetch sorted price levels.

• Enable efficient price discovery by listing NFTs based on indexed prices.

3.5 Handling Partial Fills

• Orders may partially fill, so the UI should update the order status dynamically.

• Example:

  • If a sell order is partially filled, update the remaining quantity.

  • If a buy order is partially accepted, adjust the requested asset count.

3.6 Preventing Front-Running

• Users should refresh their data before confirming trades.

• Frontend applications can pre-check availability before calling accept_offer.