Skip to main contentA-REX Core

Whitepaper · 10

Сценарии использования

Шесть сценариев, показывающих, как четыре интерфейса A-REX Core вместе с хуками охватывают ситуации, с которыми на практике сталкиваются зерновой элеватор, кооператив, экспортёр, кредитор и регулятор. Каждый сценарий называет задействованные вызовы.

1. Хранящееся зерно и складские расписки

Ситуация. Кооперативный элеватор принимает от участника 250 т пшеницы, выдаёт депозитный сертификат и позднее продаёт лот двумя частями.

Ончейн.

  1. createBatch({commodity: HS:100199, unit: KGM, producedAt: harvest, expiresAt: 0, originRef: hash(certificate #CD-88213), metadataHash, uri}, 250_000, member) — токен ссылается на юридическую расписку; он не заменяет её, пока этого не допустит юрисдикция.
  2. setBatchStatus(id, 1 /* IN_STORAGE */, ref("SILO-3")) выполняет элеватор (STATUS_ROLE).
  3. transform(member, buyerA, [id], [100_000], [same commodity/unit], [100_000], ref("SALE-1")) — переформирование партии, роль не требуется; parentsOf(newId) == [id].
  4. Вторая продажа выполняется аналогично; оставшиеся 50 т остаются в исходном id.
  5. При физическом вывозе единицы покупателя сжигаются: burn(buyerA, newId, 100_000); элеватор погашает родительский лот, когда тот пуст.

Почему это важно. Предложение точно (totalSupply), происхождение — цепочка событий BatchTransformed, а реестр расписок остаётся авторитетным.

2. Финансирование до уборки урожая (CPR, форвард, варрант на будущий урожай)

Ситуация. Бразильский производитель выпускает электронную CPR на 1,000 т сои, подлежащей уборке в апреле; кредитор авансирует средства под неё.

Ончейн.

  1. createBatch({commodity: HS:120190, unit: TNE, producedAt: 0, expiresAt: 0, originRef: hash(CPR-e registry id), …}, 1000, producer) — producedAt == 0 — это представление будущего лота в стандарте.
  2. ExpiryHook(allowPreHarvestTransfers = true), чтобы дебиторскую задолженность можно было уступить; спотовая торговая площадка развернула бы его с false.
  3. Обеспечительный интерес кредитора: setFrozenTokens(producer, id, 1000) от имени ENFORCER_ROLE (платформа, действующая по договору залога). Производитель сохраняет право собственности, но не может перемещать единицы.
  4. При уборке урожая: setBatchMetadata с весовой квитанцией; setBatchStatus(id, 2 /* HARVESTED */); платформа записывает producedAt в метаданные (ончейн-поле неизменяемо по построению; изменение статуса — ончейн-факт).
  5. Возврат кредита: setFrozenTokens(producer, id, 0). Дефолт: forcedTransfer(producer, lender, id, 1000) по залогу.

Почему это важно. Два самых распространённых кредитных события в сельском хозяйстве — залог и обращение взыскания — это два вызова, оба поддаются аудиту, оба совместимы с «контролем» по UCC, статья 12, и с инструментами на основе реестров.

3. Экспорт кофе по EUDR

Ситуация. Колумбийский экспортёр отправляет 20 т зелёного кофе обжарщику в Гамбург после 30 декабря 2026 г.

Ончейн.

  1. createBatch({commodity: HS:090111, unit: KGM, producedAt: harvest, originRef: hash(DDS reference), …}, 20_000, exporter). Полигоны участков остаются в информационной системе ЕС и в хранилище экспортёра с ограниченным доступом.
  2. Сотрудник экспортёра по комплаенсу — доверенный эмитент по теме EUDR:DDS: attest(id, EUDR:DDS, hash(DDS reference), 0).
  3. AttestationHook.setRequirement(HS:090111, EUDR:DDS) на токене: переводы кофе без аттестации возвращают ATTESTATION_MISSING.
  4. Продажа: safeTransferFrom(exporter, roaster, id, 20_000, data); обжарщик как оператор ниже по цепочке хранит ссылку на DDS в течение пяти лет — она находится в метаданных партии, которые теперь в его распоряжении.
  5. Обжарка: transform(roaster, roaster, [id], [20_000], [{commodity: HS:090121, …}], [16_800], ref("ROAST-2027-03")) — родители обжаренного лота указывают на зелёный лот и через него на DDS.

Почему это важно. Цепочка ссылок, предусмотренная регламентом, переживает переработку, а геоданные, которые, по указанию EDPB, не должны находиться в публичной сети, там никогда не оказываются.

4. Скоропортящаяся продукция и холодовая цепь

Ситуация. Фасовщик отправляет клубнику со сроком годности 12 дней; в пути фиксируется выход температуры за допустимые пределы.

Ончейн.

  1. createBatch({commodity: GTIN:…, unit: BX, producedAt: packDate, expiresAt: packDate + 12 days, …}, 4_800, packer); метаданные содержат код лота прослеживаемости FSMA, назначенный при первичной упаковке.
  2. ExpiryHook блокирует любой перевод после expiresAt (BATCH_EXPIRED); сжигание для списания остаётся возможным.
  3. Хук холодовой цепи (DeliveryHook) возвращает IN_TRANSIT во время перевозки и записывает контрольные точки в onExecuted.
  4. Выход за пределы аттестуется логистическим провайдером: attest(id, COLDCHAIN:EXCURSION, hash(sensor log), 0); хук на стороне покупателя может отказать в приёмке (политика canReceive), либо стороны урегулируют вопрос офчейн, используя аттестацию как доказательство.
  5. Доставка: burn получателем или setBatchStatus(id, 255 /* RETIRED */, ref("DELIVERED")) фасовщиком.

Почему это важно. Срок годности, хранение и инциденты качества — три независимых хука над одной записью партии; ни один из них не потребовал изменения токена.

5. Распределение в кооперативе и расчёты с участниками

Ситуация. Кооператив реализует объединённый лот в 1,000 т и должен распределить выручку и остаточное зерно между 40 участниками.

Ончейн.

  1. Участники поставляют зерно в пул: каждая поставка — это createBatch на участника, затем transform(member, coop, [ids], [amounts], [pool spec], [amount], ref("POOL-2026")), объединяющий в лот пула (переформирование партий, роль не требуется при том же товаре и той же единице измерения).
  2. parentsOf(pool) перечисляет каждую поставку участников — ключ распределения находится ончейн.
  3. Продажа пула покупателю: один safeTransferFrom.
  4. Остатки: transform(coop, coop, [pool], [remaining], [40 outputs], [per-member amounts], ref("RESIDUAL")) и safeBatchTransferFrom участникам.

Почему это важно. Объединение в пул и разделение пула, которые сегодня существуют в книгах кооперативов, — операции родословной с точными количествами.

6. Отзыв

Ситуация. Лаборатория обнаруживает афлатоксин выше допустимого предела в лоте кукурузы, который уже был разделён и частично переработан.

Ончейн.

  1. Лаборатория (доверенный эмитент по теме LAB:AFLATOXIN) аттестует результат: attest(id, LAB:AFLATOXIN, hash(report), 0).
  2. Платформа погашает лот: setBatchStatus(id, 255, ref("RECALL-2026-07")); переводы немедленно прекращаются (ARexBatchRetired), сжигание (уничтожение) остаётся возможным.
  3. Прослеживание вперёд: каждое событие BatchTransformed, у которого inputIds содержит id, даёт дочерние партии; рекурсивно — затронутые лоты кормов и продуктов питания. Прослеживание назад: parentsOf.
  4. Регулятор получает из журнала событий список затронутых id и держателей — требование о 24 часах выполняется запросом к индексатору, а не поиском по документам.

Почему это важно. Объём отзыва определяется графовым запросом по стандартизированным событиям, и именно это призвано обеспечить CTE «преобразование» из FSMA 204.

Что общего у этих сценариев

  • Четыре интерфейса, три эталонных хука и реестр аттестаций покрывают все шесть; ни одному сценарию не потребовалось изменение стандарта.
  • Правовые инструменты (расписки, CPR-e, DDS, лабораторные отчёты) — на них ссылаются и их хешируют, но не реализуют заново.
  • Принудительное исполнение (заморозка, принудительный перевод, погашение) присутствует в каждом сценарии финансирования и комплаенса и всегда является событием.
  • Персональные данные никогда не появляются ончейн.