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.

PreviousBatch Accept Buy OffersNextIntroduction

Last updated