@ninsei-labs/sdk 0.39.0 → 0.39.2

package/engine/core/config.js

@@ -365,7 +365,16 @@ export const CHAINS = [
     // селектор predict 0x3d81fc01) и касса 0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512 (573 байта, но ДРУГОЙ
     // сборки - keccak 0x5c32bb9c…): её код не совпадал с канонической кассой, и эскроу отверг бы такой ордер
     // по #122 - поэтому касса развёрнута заново тем же заходом.
-    escrow: { address: "0xcbEAF3BDe82155F56486Fb5a1072cb8baAf547cc", mode: "live", cashier: "0x1429859428C0aBc9C2C47C8Ee9FBaf82cFA0F20f" },
+    // ХЕШ КОДА РЕАЛИЗАЦИИ ЭСКРОУ (#114): то, что исполняет клон каждого ордера и что интерфейс обязан
+    // сверить сам, а не только довериться фабрике. Значение - keccak256 runtime-кода NinseiEscrow, взято
+    // из СВОЕЙ сборки: forge inspect NinseiEscrow deployedBytecode --root mvp/contracts и keccak (совпало
+    // с keccak256(type(NinseiEscrow).runtimeCode), которое записывает фабрика, и с артефактом out/).
+    // У реализации НЕТ immutables, поэтому это КОНСТАНТА ПРОТОКОЛА - один и тот же хеш в любой сети со
+    // сборкой #114. Лежит при сети, а не одним общим числом, потому что политика может отсутствовать: сеть
+    // со СТАРОЙ фабрикой (без implementation()) обязана остаться БЕЗ политики, иначе чтение пары откажет и
+    // живые котировки этой сети встанут. Так и есть у arbitrum-sepolia: развёрнутая там фабрика сборки #114
+    // не знает (оба геттера revert-ят), поэтому у неё поля НЕТ; включается тем же заходом, что и новый деплой.
+    escrow: { address: "0xcbEAF3BDe82155F56486Fb5a1072cb8baAf547cc", mode: "live", cashier: "0x1429859428C0aBc9C2C47C8Ee9FBaf82cFA0F20f", implementationCodeHash: "0xfd1ef12c1d96d3ee7060bd5901e06108723783403fad00c9630dcdeb6193674b" },
     // Токенов в песочнице нет: расплата идёт нейтивом. Пустой список - это факт о песочнице, а не забывчивость.
     tokens: [],
     // Uniswap в песочнице не развёрнут и не нужен: тут своя цепочка для сквозных прогонов, а DEX-нога
@@ -692,6 +701,18 @@ export function knownFactoryCodesFor(chainOrId) {
   return list.map((h) => String(h).toLowerCase());
 }
 
+// СПИСОК ИЗВЕСТНЫХ СБОРОК РЕАЛИЗАЦИИ ЭСКРОУ - ПОЛИТИКА ИНТЕРФЕЙСА (#114), при самой сети, где живёт адрес
+// фабрики (escrow.address). Хеш её кода - КОНСТАНТА ПРОТОКОЛА (у реализации нет immutables), но политика
+// может быть не задана: у сети без поля implementationCodeHash её НЕТ (старая фабрика пары не отдаёт).
+// Пусто = политики нет; непусто = интерфейс торгует только через фабрики, ведущие на эту сборку.
+export function knownImplementationCodesFor(chainOrId) {
+  const id = typeof chainOrId === "string" ? chainOrId : chainOrId && chainOrId.id;
+  const chain = CHAINS.find((c) => c.id === id) || chainById(id);
+  const pinned = chain && chain.escrow ? chain.escrow.implementationCodeHash : null;
+  if (typeof pinned !== "string" || !/^0x[0-9a-fA-F]{64}$/.test(pinned)) return null;
+  return [pinned.toLowerCase()];
+}
+
 export function chainById(id) {
   return CHAINS.find((c) => c.id === id) || CHAINS.find((c) => c.id === DEFAULT_CHAIN) || CHAINS[0];
 }
@@ -795,7 +816,13 @@ export const API = {
 // но это только вредило: адреса в мок-режиме выглядели как mainnet (префикс 4), а живая нода -
 // stagenet (префикс 5), и в одном UI соседствовали две цепи. Смешение цепей в свопе означает
 // потерянные деньги (см. monero/address.js), поэтому теперь и мок, и живой режим - stagenet.
-export const XMR_NETWORKS = { app: "stagenet", mock: "stagenet" };
+//
+// ПЛЮС ЗНАКОМОЕ ИМЯ REGTEST. Ключи app/mock отвечают на вопрос «в какой сети кошелёк этого источника».
+// Третья запись источника не имеет: fakechain - официальное имя regtest-режима monerod, которым нода
+// называет себя на контуре CI. Она нужна, чтобы имя сети ПРИНИМАЛОСЬ: ядро сверяет xmrNetwork со списком
+// сетей движка (sdk/src/config.mjs, STANDARD_XMR_NETWORKS), а адаптер кошелька ядра берёт список сетей
+// из ЭТОГО реестра (sdk/src/adapters/monero-wallet.mjs). Кошелёк демки при этом остаётся stagenet.
+export const XMR_NETWORKS = { app: "stagenet", mock: "stagenet", fakechain: "fakechain" };
 
 // Страница sweep: отдельный домен со своей (более строгой) политикой и WASM-кошельком.
 // Вывод XMR делает сам пользователь там, по своему recovery-файлу - демка за него не подписывает

package/engine/core/sellWindow.js

@@ -1,43 +1,43 @@
-// GENERATED FILE - a byte-for-byte copy of the engine module www/js/core/sellWindow.js for the SDK package.
-// Edit the source under www/js, then run: node tools/build-sdk-engine.mjs
-// tools/check-sdk-engine.mjs reddens on any drift, so a stale copy cannot ship silently.
-// Everything below this header is identical to the source.
-
-// ОКНО ПРОДАЖИ XMR (issue #111): ОДНО ПРАВИЛО НА ДВЕ СТОРОНЫ, А НЕ ДВА ЧИСЛА.
-//
-// ЗАЧЕМ ОТДЕЛЬНЫЙ МОДУЛЬ. У окна продажи XMR (человек отдаёт XMR, получает натив сети) два числа, и они
-// разной природы:
-//   * ЖЁСТКОЕ (hard) - срок отметки готовности ИЗ КОНТРАКТА. Позже него отметку не примет никто, и он входит
-//     в ПРИВЯЗКУ ордера (termsHash), поэтому после выдачи билета не меняется. В контракт ВСЕГДА идёт максимум:
-//     10 подтверждений Monero - это примерно 1200 с, и меньше контрактного окна быть не может, иначе отметить
-//     готовность было бы нечем (отметку контракт после readyBy запрещает, XMR заперлись бы для обоих).
-//   * МЯГКОЕ (soft) - ОБЕЩАНИЕ НА ЭКРАНЕ: сколько провайдер держит цену, пока человек отправляет XMR.
-//     "Десять минут" владельца и партнёра.
-// ПРАВИЛО ПРОДЛЕНИЯ ОДНО. Пока в пуле НЕ видно ПОЛНОЙ ожидаемой суммы, обещание продлевается до контрактного
-// максимума: человек мог отправить, и ему нужен первый блок. Как только полная сумма видна в пуле, окно
-// мягкое - обещание сдержано, и продлевать нечего.
-//
-// ПОЧЕМУ ФУНКЦИЯ, А НЕ ДВА ЧИСЛА В ДВУХ МЕСТАХ. Это правило решает НОДА (rfq/reverseArrival.mjs - отметка,
-// тревога, ранний возврат) и показывает СТРАНИЦА (www/js/core/swap.js - отсчёт на экране). Вторая редакция
-// разошлась бы с первой молча: человек видел бы одно окно, а нода жила бы по другому. Направление импорта
-// rfq -> www в проекте уже принято (образец: rfq/reverseGas.mjs импортирует ../www/js/evm/claimGas.js).
-export const SELL_WINDOW = {
-  softSec: 600,     // "десять минут": обещание провайдера на экране
-  hardSec: 1200,    // контрактное окно: 10 подтверждений Monero, максимум, попадающий в termsHash
-};
-
-const positiveSec = (v, dflt) => {
-  const n = Number(v);
-  return Number.isFinite(n) && n > 0 ? Math.floor(n) : dflt;
-};
-
-// СКОЛЬКО СЕКУНД ИДЁТ ОКНО ПРОДАЖИ при названном состоянии пула. poolSeen - в пуле видна ПОЛНАЯ ожидаемая
-// сумма, и только она (не "что-то видно" и не недоплата: сделка повисла бы на чужой копейке - см. poolCoverage
-// в rfq/reverseArrival.mjs). Контрактное окно - ПОТОЛОК: мягкое обещание не может быть длиннее контрактного,
-// иначе мы обещали бы то, чего цепь не даст.
-export function sellWindowSec({ poolSeen, soft = SELL_WINDOW.softSec, hard = SELL_WINDOW.hardSec } = {}) {
-  const s = positiveSec(soft, SELL_WINDOW.softSec);
-  const h = positiveSec(hard, SELL_WINDOW.hardSec);
-  const promised = Math.min(s, h);
-  return poolSeen ? promised : h;
-}
+// GENERATED FILE - a byte-for-byte copy of the engine module www/js/core/sellWindow.js for the SDK package.
+// Edit the source under www/js, then run: node tools/build-sdk-engine.mjs
+// tools/check-sdk-engine.mjs reddens on any drift, so a stale copy cannot ship silently.
+// Everything below this header is identical to the source.
+
+// ОКНО ПРОДАЖИ XMR (issue #111): ОДНО ПРАВИЛО НА ДВЕ СТОРОНЫ, А НЕ ДВА ЧИСЛА.
+//
+// ЗАЧЕМ ОТДЕЛЬНЫЙ МОДУЛЬ. У окна продажи XMR (человек отдаёт XMR, получает натив сети) два числа, и они
+// разной природы:
+//   * ЖЁСТКОЕ (hard) - срок отметки готовности ИЗ КОНТРАКТА. Позже него отметку не примет никто, и он входит
+//     в ПРИВЯЗКУ ордера (termsHash), поэтому после выдачи билета не меняется. В контракт ВСЕГДА идёт максимум:
+//     10 подтверждений Monero - это примерно 1200 с, и меньше контрактного окна быть не может, иначе отметить
+//     готовность было бы нечем (отметку контракт после readyBy запрещает, XMR заперлись бы для обоих).
+//   * МЯГКОЕ (soft) - ОБЕЩАНИЕ НА ЭКРАНЕ: сколько провайдер держит цену, пока человек отправляет XMR.
+//     "Десять минут" владельца и партнёра.
+// ПРАВИЛО ПРОДЛЕНИЯ ОДНО. Пока в пуле НЕ видно ПОЛНОЙ ожидаемой суммы, обещание продлевается до контрактного
+// максимума: человек мог отправить, и ему нужен первый блок. Как только полная сумма видна в пуле, окно
+// мягкое - обещание сдержано, и продлевать нечего.
+//
+// ПОЧЕМУ ФУНКЦИЯ, А НЕ ДВА ЧИСЛА В ДВУХ МЕСТАХ. Это правило решает НОДА (rfq/reverseArrival.mjs - отметка,
+// тревога, ранний возврат) и показывает СТРАНИЦА (www/js/core/swap.js - отсчёт на экране). Вторая редакция
+// разошлась бы с первой молча: человек видел бы одно окно, а нода жила бы по другому. Направление импорта
+// rfq -> www в проекте уже принято (образец: rfq/reverseGas.mjs импортирует ../www/js/evm/claimGas.js).
+export const SELL_WINDOW = {
+  softSec: 600,     // "десять минут": обещание провайдера на экране
+  hardSec: 1200,    // контрактное окно: 10 подтверждений Monero, максимум, попадающий в termsHash
+};
+
+const positiveSec = (v, dflt) => {
+  const n = Number(v);
+  return Number.isFinite(n) && n > 0 ? Math.floor(n) : dflt;
+};
+
+// СКОЛЬКО СЕКУНД ИДЁТ ОКНО ПРОДАЖИ при названном состоянии пула. poolSeen - в пуле видна ПОЛНАЯ ожидаемая
+// сумма, и только она (не "что-то видно" и не недоплата: сделка повисла бы на чужой копейке - см. poolCoverage
+// в rfq/reverseArrival.mjs). Контрактное окно - ПОТОЛОК: мягкое обещание не может быть длиннее контрактного,
+// иначе мы обещали бы то, чего цепь не даст.
+export function sellWindowSec({ poolSeen, soft = SELL_WINDOW.softSec, hard = SELL_WINDOW.hardSec } = {}) {
+  const s = positiveSec(soft, SELL_WINDOW.softSec);
+  const h = positiveSec(hard, SELL_WINDOW.hardSec);
+  const promised = Math.min(s, h);
+  return poolSeen ? promised : h;
+}