Маркетплейс Getgems

Getgems — крупнейший NFT-маркетплейс в экосистеме TON, и понимание его протокола продажи необходимо для интеграции ваших NFT-коллекций. Протокол Getgems определяет, как происходят листинг, покупка и роялти на уровне смарт-контрактов. Знание этого протокола позволяет создавать NFT-коллекции, совместимые с маркетплейсом, и понимать, как защищены сделки между покупателем и продавцом.

В предыдущих уроках мы разобрали NFT-коллекции (TEP-62) и SBT (TEP-85). Теперь посмотрим, как NFT торгуются на практике. Getgems — крупнейший NFT-маркетплейс в экосистеме TON, и его архитектура наглядно демонстрирует принцип “маркетплейс как протокол контрактов”.

Архитектура: маркетплейс как протокол

На Ethereum маркетплейсы (OpenSea, Blur) обычно работают через один центральный контракт с order book. На TON подход принципиально другой:

Каждое объявление о продаже — это отдельный Sale-контракт. Нет центрального order book. Маркетплейс — это набор стандартных контрактов для различных типов продаж.

Листинг: продажа по фиксированной цене

Поток создания листинга

1. Владелец деплоит Sale-контракт с параметрами:

   • nft_address — адрес NFT Item для продажи
   • full_price — цена в TON
   • marketplace_address — адрес для комиссии маркетплейса
   • marketplace_fee — процент комиссии (обычно 2.5%)
   • royalty_destination — адрес для royalty
   • royalty_amount — процент royalty

2. Владелец переводит NFT в Sale-контракт:

   • NFT Item меняет owner на адрес Sale-контракта
   • NFT теперь “заблокирован” в Sale (эскроу)

3. Sale-контракт готов к покупке

Владелец         NFT Item #42       NftSale контракт
  |                   |                    |
  |-- deploy Sale ----|                    |
  |                   |              [создан Sale]
  |-- transfer NFT -->|                    |
  |                   |-- owner = Sale --->|
  |                   |                    |
  | NFT заблокирован в Sale (эскроу)       |

Поток покупки

1. Покупатель отправляет TON в Sale-контракт (>= full_price)
2. Sale-контракт распределяет средства:
   • Продавец получает: full_price - marketplace_fee - royalty
   • Маркетплейс получает: marketplace_fee
   • Создатель коллекции получает: royalty_amount
3. Sale-контракт переводит NFT покупателю (меняет owner)
4. Sale-контракт самоуничтожается (больше не нужен)

Покупатель       NftSale             Продавец    Маркетплейс   Автор
  |                |                    |            |           |
  |-- TON -------->|                    |            |           |
  |                |-- TON (цена) ----->|            |           |
  |                |-- TON (комиссия) --|----------->|           |
  |                |-- TON (royalty) ---|------------|---------->|
  |                |                    |            |           |
  |<-- NFT --------|                    |            |           |
  |                |                    |            |           |
  |          [Sale уничтожен]           |            |           |

Аукцион (English Auction)

Getgems поддерживает аукционы с возрастающими ставками:

Параметры аукциона

Поток аукциона

1. Владелец деплоит Auction-контракт и переводит NFT
2. Участники делают ставки, отправляя TON в Auction-контракт
3. При новой ставке, предыдущий лидер получает возврат
4. Если ставка в последние step_time секунд — таймер продлевается
5. По истечении end_time — последний ставивший получает NFT
6. Если ставка >= max_bid — instant buy (аукцион завершается сразу)

Участник A        NftAuction         Участник B
  |                   |                   |
  |-- bid 10 TON ---->|                   |
  |              [лидер: A, 10 TON]       |
  |                   |<-- bid 15 TON ----|
  |<-- возврат 10 TON-|                   |
  |              [лидер: B, 15 TON]       |
  |                   |                   |
  | ... end_time ...  |                   |
  |                   |-- NFT ----------->|
  |                   |-- TON -> продавец |
  |             [Auction уничтожен]       |

Royalty: отчисления создателю

Royalty — это процент от каждой перепродажи, который автоматически отправляется создателю коллекции. На TON royalty реализован на уровне Collection-контракта:

Sale/Auction-контракты запрашивают royalty_params у Collection перед распределением средств. Это гарантирует, что создатель получает свою долю при каждой продаже на любом маркетплейсе, использующем стандартные контракты.

Распределение средств при продаже за 100 TON

Безопасность Sale-контрактов

Sale как эскроу

Sale-контракт работает как эскроу: NFT заблокирован в контракте до покупки или отмены. Это обеспечивает атомарность сделки — покупатель платит TON и гарантированно получает NFT.

Отмена листинга

Только продавец (original owner) может отменить Sale:

1. Продавец отправляет cancel в Sale-контракт
2. Sale переводит NFT обратно продавцу
3. Sale самоуничтожается

Риски и проверки

Архитектурные принципы

1. Децентрализация через контракты

Нет единого контракта маркетплейса — каждый Sale независим. Это означает:

• Нет single point of failure
• Нет цензуры (никто не может “заблокировать” отдельный Sale)
• Маркетплейс-фронтенд может упасть, но контракты работают

2. Composability

Sale-контракты могут взаимодействовать с другими протоколами:

• DEX-контракт может участвовать в аукционе
• DAO может автоматически покупать NFT через governance proposal
• Lending-протокол может принять NFT как залог

3. Параллелизм

Тысячи Sale-контрактов работают параллельно в разных шардах. Нет bottleneck от единого order book. Каждая покупка — независимая транзакция в шарде Sale-контракта.

Экосистема NFT-маркетплейсов TON

Итоги модуля M05

За 6 уроков мы разобрали шардированную архитектуру токенов TON:

Главный инсайт: каждый баланс, каждый NFT, каждый SBT — это отдельный контракт. Это фундаментальное отличие TON от Ethereum и ключ к пониманию всей экосистемы.

В следующем модуле (M06) мы разберём, как эта архитектура применяется в DeFi: DEX, lending, staking.

Частые ошибки

1. Не реализуют стандартный интерфейс sale-контракта Getgems, без которого NFT не смогут продаваться на маркетплейсе.
2. Забывают о комиссиях маркетплейса и royalty при расчёте конечной цены: пользователь платит сверх указанной цены, и это должно быть отражено в UI.
3. Не верифицируют подлинность sale-контракта при покупке, что позволяет злоумышленнику создать поддельный контракт продажи для фишинга.
4. Игнорируют механизм отмены продажи (cancel sale): продавец должен иметь возможность снять NFT с продажи в любой момент.