Розробка системи phygital NFT (фізичне + цифрове)
Головна проблема phygital — розрив між цифровим токеном та фізичним об'єктом. Смарт-контракт зберігає права власності безупречно. Фізичний світ — ні. Хтось може зробити точну копію кроссовок, відклеїти NFC-чип, продати «оригінал» двічі. Вся складність phygital зводиться до одного запитання: як технічно забезпечити, що конкретний фізичний об'єкт пов'язаний саме з цим токеном — і цей зв'язок неможна розірвати або підробити.
Механізми привязки фізичного до цифрового
NFC-чипи з криптографією (PBT — Physical Backed Token)
Azuki запропонував стандарт PBT (EIP-5791), який використовує NFC-чипи Kong/Arx з захищеними ключами. Чип генерує пару ключів всередину secure element, приватний ключ ніколи не покидає чип. При сканованні чип підписує сообщение, що містить адресу сканера + block hash (захист від replay):
function transferTokenWithChip(
bytes calldata signatureFromChip,
uint256 blockNumberUsedInSig,
bool useSafeTransferFrom
) external;
Смарт-контракт верифікує підпис через ecrecover, порівнює восстановленую адресу з зареєстрованою адресою чипу. Трансфер токена можливий тільки тому, хто фізично тримає об'єкт в руках. Проблема: чип можна фізично перенести на інший предмет. Рішення — епоксидна заливка або інтеграція чипу в матеріал об'єкта.
QR-коди з одноразовими токенами
Простіше в реалізації, але слабше в безпеці. Підходить для тимчасової верифікації (вход на мероприятие), не для підтвердження постійного володіння. QR генерує одноразову підпис сервера, контракт перевіряє її та спалює nonce.
Oracles для фізичної верифікації
Для ювелірних виробів та предметів колекціонування: фізична верифікація через доверених oracles (Chainlink CCIP + custodial мережа партнерів). Об'єкт проходить верифікацію в авторизованому центрі, oracle публікує аттестацію на-чейн, NFT отримує verified-статус. Працює для високовартісних предметів, де вартість верифікації виправдана.
Архітектура смарт-контрактів
Базова структура phygital NFT
contract PhygitalNFT is ERC721, IPBT {
mapping(uint256 => address) public tokenChipAddress;
mapping(address => uint256) public chipAddressToTokenId;
mapping(uint256 => PhygitalData) public tokenData;
struct PhygitalData {
bytes32 physicalId; // хеш унікального ідентифікатора об'єкта
uint256 verifiedAt; // timestamp останньої верифікації
address verifier; // oracle/верифікатор
PhysicalStatus status; // INTACT, DAMAGED, DESTROYED
}
}
Lifecycle события
Phygital NFT проходить через стани, яких нема в чисто цифрових токенах:
Minting: фізичний об'єкт створений + чип зареєстрований → NFT заминчен. Transfer: верифікація через чип обов'язкова для on-chain трансфера (PBT-стиль) або опціональна (trust режим для маркетплейсів). Redemption: власник «активує» фізичний об'єкт, токен burn або locked. Для fashion (носиш кроссовки — «тратиш» NFT). Destruction: фізичний об'єкт знищений — NFT стає історичним артефактом без фізичного backing.
Dual-mode ownership
Многі проекти розділяють digital rights та physical custody:
mapping(uint256 => address) public physicalCustodian; // хто зберігає фізично
// ownerOf() — цифровий власник (може бути іншим)
Дозволяє торгувати цифровим токеном на вторинному ринку, не переміщуючи фізичний об'єкт (який може знаходитися в secured vault). При redemption новий власник ініціює фізичну доставку.
Інтеграція з маркетплейсами
OpenSea та інші працюють з ERC-721/1155 без розуміння phygital-специфіки. Потрібні додаткові шари:
Metadata: атрибут physical_verification_required: true + ссилки на сертифікати. Кастомна сторінка проекту (не стандартна OpenSea) для повного отображення фізичних даних.
Transfer-хуки: override _beforeTokenTransfer() для перевірки фізичного статусу перед продажею. Якщо помічений DAMAGED або UNVERIFIED — попередження або блокування залежно від політики.
Escrow для фізичної доставки: при продажу токен блокується в escrow, продавець підтверджує відправлення з tracking number, покупець підтверджує отримання — тоді escrow release. Спорні ситуації — арбітраж через Kleros або централізований resolver.
Backend та інфраструктура
Phygital вимагає серйозного off-chain шару:
NFC верифікація backend: API для валідації чип-підписів, маппинг chipAddress → tokenId, історія сканувань. Обов'язково rate limiting — запобігання brute-force атак на block hash простір.
Фізичний реєстр: база даних з детальними описами об'єктів, фотографіями високої розрізнювальної здатності, сертифікатами автентичності, історією обслуговування. Хеш цих даних фіксується on-chain; повний масив — off-chain.
Oracle network: для проектів з регулярною верифікацією (luxury goods, art) — мережа верифікаторів з stake та slashing за невірні аттестації.
Типові use cases та їхня специфіка
| Use case | Механізм привязки | Redemption | Складність |
|---|---|---|---|
| Luxury fashion | NFC Kong + PBT | Одноразовий burn | Висока |
| Колекційні карти | QR + backend | Повторна, без burn | Середня |
| Ювелірні вироби | Oracle-верифікація | Ні (vault custody) | Висока |
| Мероприятия/білеты | QR одноразовий | Одноразовий burn | Низька |
| Вино/spirits | NFC + temp sensors | При відкритті пляшки | Дуже висока |
Орієнтири по строкам
Базова система (PBT + mint + верифікація): 1 тиждень. Повна система з escrow-маркетплейсом, oracle-верифікацією та backend: 2-3 тижні залежно від вимог до фізичної інфраструктури.







