FEEx — концепция проекта и руководство разработчика

FEEx (Financial Equivalents Exchange system) — публичный блокчейн-протокол и веб-приложение для выпуска и оборота токенбон: NFT-токенизированных банкнот и монет, обеспеченных страховым фондом в биткоинах. Бывшее название проекта — NFT-Banknote Digital Collection (NFT-BDC).

Этот документ — структурированная сводка содержимого книги разработчика (39 HTML-глав в FEEx-book_dev/) + результаты последующих обсуждений архитектуры и доработок.

Концепция простыми словами

FEEx — это цифровые банкноты с реальным биткоин-обеспечением и приватностью «запечатанного конверта».

Каждая токенбона одновременно:

NFT в собственном блокчейне FEEx с подписью Контракта = доказательство неподделки.
Картинка-купюра с серией, номером и кодом РКЦ-эмитента.
Свой обёрточный кошелёк FBTC в нашем confidential-сайдчейне, под которым в multisig 6/8 у Судей лежит реальный BTC.

Бо́ны ходят как стейблкоины — по номиналу. Никто не знает, сколько именно BTC под конкретной бо́ной — даже её владелец, даже примерно. При выпуске обеспечение всех бо́н одинаковое (80% по курсу момента); ежемесячное confidential-mix рандомно перетасовывает балансы между кошельками — на одной может оказаться $1, на другой $100. Реальная лотерея. Хотите гарантированный $20 — пользуйтесь как деньгами. Хотите вытащить BTC — гасите на свой страх и риск.

Пример: как Вася покупает $20-бону

Вася в МП выбирает «Купить → USD → $20 → 1 шт». Цена — около $25 в BTC по курсу.
РКЦ присылает Васе биткоин-адрес. Вася переводит 0.00060632 BTC.
Контракт автоматически:
- 80% ($16) → multisig FEEx (BTC физически заперт под FROST 6/8 наших Судей).
- В нашем сайдчейне выпускается эквивалент FBTC — confidential-токенов с зашифрованным балансом.
- 10% — РКЦ за работу, 10% — Системе на инфраструктуру.
- FBTC попадает на свежий confidential-кошелёк именно этой бо́ны.
- Минтится NFT-бо́на с картинкой, серией+номером и подписью Контракта.
- NFT отправляется Васе через МП.
У Васи в кошельке «$20 банкнота». Балансы FBTC физически невидимы извне (Pedersen commitments + Bulletproofs); связь «бо́на ↔ кошелёк» зашифрована в Threshold-ElGamal реестре Контракта.
Контракт публикует ZK-доказательство: «у нас в сумме хватает BTC на покрытие всех бо́н в обороте». Любой математически проверяет.

Передача Васи → Маше — бесплатна (РКЦ платит газ через Paymaster). Маша получает бо́ну, не зная её внутренний баланс. Если погасит через год — получит то, что окажется на её confidential-кошельке после ежемесячных перетасовок: может $5, может $80.

Что отличает от стейблкоинов

Аспект	USDT/USDC	Токенбона FEEx
Эмитент	один (Tether/Circle)	сеть РКЦ + сторонние эмитенты через FaaS
Обеспечение	доллары на банковском счёте	реальный BTC в multisig 6/8 наших Судей
Прозрачность резерва	отчёт раз в квартал, доверять компании	публичный multisig + ZK-proof покрытия каждый блок
Видимость баланса конкретной единицы	(нет понятия «единица»)	физически невидим через Confidential Transactions
Заморозка кошелька эмитентом	возможна	архитектурно невозможна (no admin keys)
Что будет, если эмитент умрёт	паника, депег	бо́ны продолжают работать; погашение через FROST у Судей
Цензура / санкции	да, прецеденты есть	архитектурно невозможна; вход через IPFS-mirror, Tor

Главные уникальные особенности

Каждая бо́на — запечатанный конверт. У каждой свой confidential FBTC-кошелёк, баланс которого никто не знает. При погашении — лотерея от $1 до $100 для $20-бо́ны, при обращении — стейблкоиновая ходимость по номиналу.
Свой confidential-сайдчейн с FROST-multisig. BTC заперт под FROST 6/8 у 8 Судей (приваткей никогда не существует целиком). Внутри FEEx ходят FBTC с Pedersen + Bulletproofs. Никаких внешних федераций.
No admin keys. В смарт-контрактах нет pause/freeze/mint без обеспечения/burn чужого. Никто не может заморозить ваш кошелёк или напечатать FBTC из ничего. Изменение правил — только через 8/8 голосование Судей с timelock 30 дней. Право погашения имеет двойной замок: его удаление требует 8/8 (а не 6/8).
Бесплатно для пользователя. Account Abstraction Paymaster — РКЦ оплачивает газ. MVIP остаётся как антиспам-лимит, пользователь его не видит.
Бумажная логика наличных в цифре. Сортировка, размен, упаковка в «конверт» (сертификат), скрытные платежи через сертификат-обёртку.
Стейк-фича. Владелец может отправить бо́ну в стейк (≥30 дней) → пропорциональная часть BTC уходит в Babylon-staking → доход распределяется по номиналам бо́н в стейке (все $20 в стейке получают равно, независимо от своего реального обеспечения).
Антицензурный вход через IPFS + Tor. Сайт пинится в IPFS под threshold-IPNS 6/8, обновляется только голосованием Судей. Удалить нельзя.
FaaS — платформа для других эмитентов. Любой проект может выпускать свои токены на нашей инфраструктуре. Тариф — единая шкала: 10% Системе с минта, как для РКЦ.
Постепенная децентрализация. Стартуем с 8 Судей (3+3 Наблюдателя + автор + разработчик), растём до 15–21 через DKG-resharing; добавляются валидаторы блокчейна и внешние аудиторы.
Open-source всё. Контракты, нода, МП, SDK. Reproducible builds. Публичная DKG-церемония. Bug bounty $50k–$1M. Формальная верификация критичных функций.

Глоссарий сокращений

Концептуальные термины (по терминологии автора FEEx)

Термин	Что означает
Единица счёта	сама токенбона как объект учёта (например `t$100`)
Мера ценности	фиксированная цена обращения боны = её номинал ($100)
Эквивалент	фиатная валюта, к которой привязан номинал (USD, EUR, JPY, …)
Мера стоимости	плавающая резервная стоимость в BTC — страховой залог в СК конкретной боны

Сопоставление с обиходными словами в этом документе: «обеспечение», «реальное обеспечение», «BTC-залог» = мера стоимости; «номинал» = мера ценности.

Сокращения

Сокр.	Расшифровка	Смысл
FEEx	Financial Equivalents Exchange	название всей системы (бывш. NFT-Banknote Digital Collection)
РКЦ	Расчётно-Кассовый Центр	узел-провайдер, выпускает токенбоны и держит шлюз. Зарабатывает 10% от номинала. Аналогия с РКЦ Банка России
Судьи	8 ключников системы	3 Наблюдателя автора + 3 Наблюдателя разработчика + автор + разработчик. Управляют через FROST 6/8
МП	Многофункциональное (веб)-Приложение	frontend для пользователя
NFT-бо́на	токенизированная банкнота	NFT в блокчейне FEEx с подписью Контракта; в приватконтенте — `IDiw` для поиска привязанного FBTC-кошелька
FBTC	Fee-BTC	обёрточный confidential-токен FEEx, привязан 1:1 к BTC в multisig Судей
СК	Страховой Кошелёк	индивидуальный confidential FBTC-кошелёк под каждой бо́ной
ЕАП	Единый Адрес Погашения	смарт-контракт; обрабатывает погашение, выпуск, mixing через FROST 6/8 + Threshold ElGamal
Peg	привязка ценности 1:1	механизм обмена BTC ↔ FBTC через multisig (peg-in / peg-out)
Multisig 6/8	пороговый кошелёк	BTC-адрес, для подписи нужны 6 из 8 Судей через FROST
MVIP	внутренний антиспам-токен сети	не покупается, циркулирует, ограничивает спам. Пользователь его не видит
НКЦ	Накопительный Кошелёк Центра	BTC-адрес РКЦ для получения комиссий
КПДС	Коэффициент Полезных Действий для Системы	репутация РКЦ; влияет на распределение клиентов
ГСК	Главный Секретный Ключ	приваткей Контракта ЕАП. Не существует целиком; разделён через FROST 6/8 + DKG между Судьями
PoA	Proof-of-Authority	механизм консенсуса блокчейна FEEx
FROST	Flexible Round-Optimized Schnorr Threshold	пороговая подпись Шнорра без доверенного дилера; ключ никогда не собирается целиком
Threshold ElGamal	пороговая расшифровка	каждый Судья частично расшифровывает своей долей; полный приваткей не существует
DKG	Distributed Key Generation	совместная генерация ключа без доверенного дилера
CT	Confidential Transactions	скрытие сумм в транзакциях через Pedersen commitments + Bulletproofs
AA	Account Abstraction (ERC-4337)	программируемые кошельки с paymasters, social recovery, batched txs
PoP	Proof-of-Personhood	криптографическое «один человек = одна личность» (World ID, Anon Aadhaar) без раскрытия имени
IPFS / IPNS	InterPlanetary File System / Name System	децентрализованное хранилище файлов и стабильное имя для обновлений
FaaS	FEEx-as-a-Service	использование инфраструктуры FEEx сторонними эмитентами для выпуска своих токенов
Mixing	ежемесячный confidential-mix	в случайный день месяца Контракт через FROST перетасовывает балансы FBTC между всеми СК. Стейканые бо́ны не участвуют
Стейк-фича	пользовательский Babylon-yield	владелец отправляет бо́ну в стейк (≥30 дней) → получает долю yield по номиналу
Return	спецтокен возврата при погашении	NFT с парой `(BTC-адрес, приваткей)` нового кошелька, куда отправлены BTC при погашении

Содержание

Что такое FEEx
Архитектура — три слоя, сеть FEEx, Bitcoin/peg, концепция «запечатанных конвертов», жизненный цикл, стейк, FaaS, доверие
МП — многофункциональное веб-приложение
Токенбоны: устройство, виды, жизненный цикл
Криптография
Главный и резервные ключи Системы
Инструменты: платежная ссылка, ваучеры, сертификаты
Наставник (реферальная программа)
Управление системой и спецтокены управления
Юрисдикции и стратегия запуска
Развёртывание и обновления (IPFS, апгрейды)
Кошельки и подключение
SDK и интеграции
Гарантии для держателей токенбон
Открытые параметры

1. Что такое FEEx

Токенбона — цифровая банкнота с реальным биткоин-обеспечением, выпущенная в собственном блокчейне FEEx и защищённая криптографической приватностью «запечатанного конверта».

Каждая токенбона — это три неделимые части:

Картинка-купюра с серией, номером, кодом РКЦ-эмитента и подписью Контракта. Генерируется на лету по графическим матрицам — в блокчейне не хранится.
NFT-токен в блокчейне FEEx с зашифрованным IDiw для поиска привязанного confidential-кошелька.
Confidential FBTC-кошелёк в нашем сайдчейне с зашифрованным балансом. Под FBTC в multisig 6/8 у Судей физически заперт реальный BTC.

Выпуск осуществляют РКЦ (Расчётно-Кассовые Центры) — независимые узлы-провайдеры, либо сторонние эмитенты через FaaS.

Ключевые свойства

Реальное обеспечение 80% при выпуске в эквиваленте BTC по курсу момента. Все бо́ны партии получают одинаково — дикий разброс между конкретными бо́нами появляется естественно после первого ежемесячного mixing.
Никто не знает баланс конкретной бо́ны — даже владелец, даже примерно. Confidential Transactions через Pedersen commitments + Bulletproofs.
Бо́ны ходят по номиналу. При погашении — лотерея от $1 до $100 для $20-боны.
Бесплатные транзакции для пользователя через Account Abstraction Paymaster (РКЦ оплачивает газ).
РКЦ получает 10% от номинала при выпуске; 10% Системе на инфраструктуру.
No admin keys — нет функций pause/freeze/mint без обеспечения. Изменения только через 8/8 Судей с timelock 30 дней.
Open-source всё: контракты, нода, МП, SDK. Reproducible builds. Публичная DKG-церемония.

2. Архитектура

В одну фразу. FEEx — это связка трёх слоёв: реальный BTC заперт в multisig 6/8 у наших Судей через FROST → внутри собственного PoA-блокчейна FEEx ходят confidential-токены FBTC (1:1 к BTC) → каждой бо́не привязан свой confidential FBTC-кошелёк, балансы которого скрыты Pedersen+Bulletproofs. Всё проверяемо публичным ZK-доказательством покрытия и open-source кодом.

2.1. Три слоя системы

Слой	Что	Где живёт	Кто управляет
NFT-бо́ны	сами токены, реестр владельцев, привязка `(IDiw → FBTC-кошелёк)` зашифрована Threshold ElGamal	блокчейн FEEx	смарт-контракт; правила меняются 8/8 Судей с timelock 30 дней
FBTC	обёрточный confidential-токен, балансы скрыты через Pedersen + Bulletproofs (см. §5.5)	блокчейн FEEx	пороговая схема Контракта ЕАП — FROST 6/8
BTC	реальные биткоины в публичной сети Bitcoin, на multisig-адресе (Taproot/P2WSH)	публичный Bitcoin	те же 8 Судей через FROST 6/8 + DKG

FBTC = 1:1 peg к BTC. При peg-in BTC из публичной сети → multisig FEEx → выпуск эквивалента FBTC в нашем блокчейне. При peg-out FBTC сжигается → BTC из multisig → пользователю.

2.2. Сеть FEEx — собственный PoA-блокчейн

Собственный блокчейн на базе Geth с расширениями для Confidential Transactions. Уникальный chain ID, собственный генезис, узлы общаются только между собой.

Роли узлов

Роль	Что делает
Валидатор (signer)	Формирует и подписывает блоки. Со временем — публичные узлы за вознаграждение, не только Судьи.
РКЦ	Авторитетный узел, выпускает токенбоны, держит публичный шлюз. Доход — 10% от номинала выпуска.
Публичный шлюз	Принимает запросы от внешних клиентов / кошельков. Не обязательно валидатор.
Балансировщик	«Нулевой» публичный шлюз, распределяющий клиентов между РКЦ по правилу коммерческой справедливости (см. §3.4).
Watchdog	Мониторят Контракт и multisig BTC; публикуют алерты при аномалиях. Голосов не имеют.

Валидаторы и РКЦ не получают награду за блоки. Бесплатность транзакций обеспечивается AA Paymaster (см. §3.5), который оплачивается из доли РКЦ.

Смарт-контракты

Контракт-1 (Базовый) — реестр РКЦ, минтинг и передача NFT-бо́н, реестр публичных ключей пользователей, аудит-лог.
Контракт ЕАП — confidential-операции с FBTC, peg-in/peg-out BTC, ежемесячный mixing, погашение. Управляется FROST 6/8 + Threshold ElGamal.
Контракт управления — голосования Судей, обновления с timelock, смена резервных мастеркеев (см. §9).
Контракт стейка — пользовательская Babylon-фича (см. §2.7).

NFT-бо́на (расширенный ERC-721)

Подпись Контракта в публичных метаданных = доказательство неподделки.
В приватконтенте — IDiw (32-байтовый идентификатор), зашифрован ECIES публичным ключом владельца (см. §5.2).
При передаче А→Б приватконтент перешифровывается с pubKey отправителя на pubKey получателя.
Гашение (burn на 0x000...000) при погашении.

MVIP — внутренний антиспам

MVIP — не «деньги», а числовой лимит активности на стороне сети. Не покупается, не продаётся, циркулирует. Пользователь его не видит.

Параметр	Значение
Стоимость 1 транзакции	0,003 MVIP
Lim1 (за каждую полученную бо́ну)	1 MVIP
Lim2 (макс. на кошельке)	5 MVIP
Lim3 (новый пустой кошелёк)	0,0001 MVIP

Защиты: антифрод-эвристика Контракта (массовое создание кошельков, цепочки через пустые адреса, возврат бо́ны в уже использованный кошелёк); привязка Lim3 к одобрению РКЦ; proof-of-personhood для критичных операций; decay 1%/мес после 6 мес неактивности; модификация опкодов create/create2 (>50 трлн MVIP для записи контракта).

Технические ограничения

Размер одной транзакции: ≤ 128 КБ.
Картинки бо́н не хранятся в блокчейне — только графические матрицы в IPFS.
РКЦ-узлы могут работать в лёгком режиме (без терабайтов диска).

2.3. Bitcoin: multisig и peg

Bitcoin — внешняя сеть, где физически хранится обеспечение. FEEx взаимодействует с ней только через peg.

Multisig FEEx:

P2WSH (Taproot multisig) — нативная поддержка Schnorr-подписей под FROST.
Управляется 8 Судьями через FROST 6/8 + DKG. Полный приваткей не существует целиком.
Адрес публичный — любой видит баланс через blockchain.com.
При расширении состава Судей — DKG-resharing меняет доли без перевода средств: адрес остаётся прежним.

Peg-in (выпуск партии бо́н):

РКЦ собирает заказы клиентов.
Контракт генерирует одноразовый peg-in адрес multisig для этого заказа.
Клиенты переводят BTC.
После N подтверждений в Bitcoin Контракт фиксирует поступление.
Распределение: 80% от номинала каждой бо́ны → постоянный multisig FEEx, 10% → НКЦ Системы, 10% → НКЦ РКЦ.
В блокчейне FEEx Контракт минтит эквивалент FBTC, распределяет равными долями между N свежими confidential-кошельками.
Минтит N NFT-бо́н, привязка (IDiw → FBTC-кошелёк) записывается в Threshold-ElGamal реестре.
NFT отправляются заказчикам.

Шаги 4–8 атомарны через FROST: либо вся партия, либо BTC возвращается.

Peg-out (погашение бо́ны):

Контракт через Threshold ElGamal расшифровывает привязку IDiw → FBTC-кошелёк.
Сжигает FBTC на этом кошельке.
Через FROST 6/8 инициирует BTC-транзакцию: с multisig FEEx → на свежий адрес → выпуск спецтокена Return владельцу.

Батчинг. Peg-in и peg-out батчатся: один multisig-вход обслуживает множество выходов в одной Bitcoin-транзакции. Параметры: цель Kopt = 10 выходов, макс. ожидание tmax = 90 мин, лимит размера Lmax = 1 МБ, окно после набора tnorm = 20 мин.

Безопасность:

BTC из multisig нельзя двигать без 6/8 подписей через FROST. Никаких бэкдоров.
Watchdog мониторит multisig: любая транзакция, не санкционированная Контрактом → аварийный алерт всем Судьям (см. §9.4).
При компрометации >5 из 8 долей — переход на резервный мастеркей с переводом BTC на новый multisig (см. §6.3).

2.4. Концепция «запечатанные конверты»

Цели проекта:

При выпуске каждая бо́на получает честные 80% обеспечения в эквиваленте BTC — публично доказывается open-source смарт-контрактом.
После выпуска никто не знает, сколько именно в конкретной бо́не — даже владелец, даже примерно. Может оказаться $1, может $100 для $20-боны.
При обращении обеспечение между бо́нами периодически перемешивается (раз в месяц).
Бо́ны ходят как стейблкоины по номиналу. Никто не «охотится на жирные» — увидеть жирные нельзя в принципе.
Желающий погасить получает то, что окажется в его конверте, на свой страх и риск. Это лотерея.

Что видит публика:

Видно	Не видно
Multisig-адрес BTC и его баланс	баланс конкретного FBTC-кошелька
Список FBTC-кошельков (только commitments)	привязка «бо́на ↔ FBTC-кошелёк»
ZK-доказательство покрытия (`сумма_FBTC ≥ долг_по_бо́нам`) каждый блок	кто из Судей подписывал какую операцию
Количество бо́н в обороте по валютам и номиналам	данные владельцев
Open-source код смарт-контракта	дата выпуска и обеспечение конкретной бо́ны
История минтов, погашений, mixings (хэши)

2.5. Жизненный цикл бо́ны

Выпуск партии — см. peg-in выше.

Передача А→Б. Вася в МП передаёт NFT Маше. Транзакция в FEEx-блокчейне, бесплатна для пользователя через AA Paymaster. Контракт обновляет реестр владельца, привязка к FBTC-кошельку остаётся прежней. Маша получает бо́ну, не зная её баланс.

Mixing (раз в месяц, в случайный день через VRF). Контракт через FROST 6/8 запускает confidential-mix всех FBTC-кошельков. Балансы между кошельками рандомно перетасовываются (общая сумма сохранена через homomorphic свойство Pedersen-commitments). Снаружи видны только commitments — невозможно отследить, что именно поменялось. Стейканые бо́ны не участвуют — их обеспечение зафиксировано.

Погашение — см. peg-out выше. Сколько окажется на FBTC-кошельке Маши в момент погашения = столько BTC она получит. Реальная лотерея от $1 до $100 для $20-боны. NFT сжигается, в аудит-лог запись (timestamp, IDiw, burnTxHash). Маше выдаётся спецтокен Return.

Прозрачность фоном. Каждые N блоков Контракт публикует bulletproof «сумма_FBTC ≥ долг_по_бо́нам». Multisig-адрес BTC публичен — любой видит сколько BTC заперто. Любой математически проверяет 1:1 peg.

2.6. Стейк-фича — Babylon-yield

Не Система стейкает обеспечение, а владельцы бо́н добровольно отправляют свои бо́ны в стейк через специальную операцию в МП.

Как работает:

Войти в стейк. Владелец в МП → «Отправить бо́ну в стейк». Бо́на блокируется в стейк-пуле.
Контракт берёт пропорциональную часть BTC из multisig (равную текущему балансу FBTC этой бо́ны на момент входа) → отправляет в Babylon-staking через peg-out.
Доход от Babylon (3–7% годовых) возвращается в общий yield-пул (отдельный confidential-кошелёк).
Yield распределяется по номиналам бо́н в стейке, не по реальному обеспечению. Все $20-бо́ны в стейке получают равную долю.
Выйти из стейка. Контракт через FROST вытаскивает BTC из Babylon → возвращает в multisig → выпускает обратно FBTC на confidential-кошелёк бо́ны → выдаёт владельцу накопленный yield в виде дополнительного FBTC.

Условия:

Минимальный срок стейка — 30 дней (окупает peg-out → Babylon → возврат).
Бо́на в стейке нельзя передать или погасить — только вынуть обратно.
Стейканые бо́ны не участвуют в общем mixing; обеспечение зафиксировано на момент входа.
Yield накапливается до выхода — выплата при выходе.

Почему по номиналам, а не по реальному обеспечению. Поддерживает идею «$20 = $20». Yield-пул — отдельная сущность, не путает базовую механику обеспечения.

2.7. FaaS — платформа для других эмитентов

Инфраструктура FEEx (confidential-сайдчейн с peg к Bitcoin, FROST-защита, mixing, AA Paymaster) может использоваться сторонними эмитентами для выпуска своих токенов и инструментов.

Что предоставляется: confidential balances для их токенов, защита через FROST 6/8, готовые mixing/peg, AA Paymaster для их пользователей, бренд проверенной open-source системы.

Тарифы — единая шкала с базовой моделью:

10% Системе с каждого минта (та же ставка, что для РКЦ).
Эмитент сам устанавливает свою маржу со своих клиентов.
Для ваучеров эмитента — $2, 50/50 эмитенту и Системе.

Никаких отдельных «залогов», «процентов с погашений», «годовых пакетов». Чем больше выпускает эмитент — тем больше получает Система. Никаких барьеров для входа малых эмитентов.

Гарантии для эмитентов FaaS — те же что у наших пользователей: Судьи не могут заморозить их активы, изменить их правила без согласия, видеть балансы или произвольно сжечь токены. Право погасить прибито архитектурно (8/8 + timelock 30 дней для изменения).

2.8. Принципы доверия — «никто не может обмануть»

Что Система НЕ может сделать с пользователями (no admin keys)

В смарт-контрактах отсутствуют функции:

❌ pause() / freeze(address) — заморозить кошелёк или операции пользователя.
❌ mint(to, amount) без 80% обеспечения — напечатать FBTC из ничего.
❌ burn(from, amount) чужой бо́ны без согласия владельца.
❌ Произвольной модификации балансов — только стандартные операции (выпуск, передача, погашение, mixing).
❌ Скрытых лазеек для разработчиков — open-source, ничего за кулисами.

Изменение правил — только 8/8 Судей с timelock 30 дней. За 30 дней любой пользователь может погасить бо́ны, если не согласен.

Право погасить — двойной замок. Проверочная функция redeem(NFT) имеет специальный флаг: её изменение требует 8/8 + timelock 30 дней вместо стандартных 6/8. Хотя бы один Судья из 8 может заблокировать удаление права погашения.

Что пользователи НЕ могут сделать с Системой

❌ Подделать бо́ну — на каждой подпись Контракта (Schnorr через FROST). Без приваткея 6/8 Судей подделка невозможна.
❌ Двойное погашение — atomic burn + transfer; повторная попытка блокируется через burnedTokens mapping.
❌ DoS-атака на сеть — MVIP-лимиты + AA Paymaster контролирует объёмы.
❌ Sybil-атака — proof-of-personhood для критичных операций + антифрод-эвристика.
❌ Минтинг без оплаты — функция выпуска требует доказательства поступления BTC на multisig.

Открытость на всех уровнях

Уровень	Что
Код	open-source: смарт-контракты, нода, МП, SDK
Аудиты	публичные отчёты от Trail of Bits, OpenZeppelin, Halborn перед запуском
Reproducible builds	бинарники собираются детерминированно
Multisig BTC	публичный адрес, баланс и движения видны
ZK-доказательство покрытия	каждый блок
DKG-церемония	публичная, верифицируется любым
Все обновления	через timelock 30 дней + публичный анонс. История неизменяема
Bug bounty	$50k–$1M за критические баги
Формальная верификация	критические участки кода (Certora, K Framework)

Постепенное расширение децентрализации

8 Судей на старте (3+3 Наблюдателя + автор + разработчик), управление через FROST 6/8.
Расширение до 15–21 Судей через DKG-resharing (без смены ГСК).
Внешние Судьи при зрелости — публичные криптоэксперты, юристы, представители экосистемы.
Открытые валидаторы блокчейна — узлы PoA за вознаграждение, без управления Контрактом.
Внешние аудиторы — без права подписи, но с правом мониторинга и публичных алертов.

3. Многофункциональное веб-приложение (МП)

МП — frontend FEEx. Каждый РКЦ держит своё МП. Все операции пользователя проходят через него: покупка, передача, размен, погашение, ваучеры, сертификаты, платёжные ссылки.

МП — «удобная приборная панель»: ограничивает функциональность ради UX, но прямое обращение к узлу блокчейна даёт полный набор операций. В самом протоколе нет скрытых ограничений — это часть принципа no admin keys.

3.1. Терминалы по уровню доступа

Терминал	Разделы навигации
Клиент	Мой Бумажник, Инструменты, Контакты, Доверие
РКЦ	+ Инструменты РКЦ (Платёжная, Партнёрская ссылки), Реестр клиентов, Статистика, НКЦ
Совет Управляющих	+ Голосования, Реестр и КПДС РКЦ, Резервные ключи, Триггеры, Аудит-лог

Языки: английский по умолчанию + локализации (русский, испанский и др.). Локализации хранятся отдельно в IPFS, обновляются threshold-IPNS 6/8.

3.2. Точка входа

Уровень	Что
Основная	нулевая страница в IPFS под threshold-IPNS 6/8; редирект на МП конкретного РКЦ по правилу коммерческой справедливости (см. §3.4)
Антицензурная	Tor `.onion`-mirror, не требует HTTPS
Резервная	прямой DNS-доступ к МП РКЦ (HTTPS через Let's Encrypt)
Локальная	собственная нода + локальное МП на машине пользователя

3.3. Подключение кошелька

Поддерживается любой EVM-кошелёк через WalletConnect v2 + Web3Modal/RainbowKit — MetaMask, Trust, Rainbow, Argent, Ledger, Coinbase Wallet, Phantom (EVM-режим) и ~300 других. EIP-1193 / EIP-6963 — стандарт injected wallets, не требует специального кода под конкретный MetaMask.

При первом подключении МП просит подписать «приветственное сообщение» → из подписи ecrecover восстанавливает публичный ключ → записывает в реестр Контракта-1. Это нужно, чтобы любой мог зашифровать приватконтент бо́ны на этот pubKey при передаче (см. §5.2).

3.4. Балансировщик и коммерческая справедливость

Нулевое МП распределяет клиентов между РКЦ по параметру КПДС (Коэффициент Полезных Действий для Системы):

по умолчанию КПДС = 1;
максимум у РКЦ автора;
РКЦ с КПДС = N получает N заказов подряд, потом очередь идёт к следующему;
среди равных по КПДС — тот, у кого меньше всего заказов.

Клиенты, которых РКЦ привёл сам (через платёжную или партнёрскую ссылку), проходят на его шлюз без очереди.

3.5. Бесплатные транзакции через Account Abstraction

Все операции пользователя оплачиваются Paymaster от РКЦ (ERC-4337). Пользователь не видит газ. MVIP идёт фоном для контроля объёмов и защиты от спама.

Дополнительные возможности через AA:

Social recovery — восстановление доступа через гарданов (заранее выбранных доверенных лиц) при утере приваткея.
Batched transactions — несколько действий за одну подпись (например, погасить 5 бо́н одной операцией).
Session keys — авторизация автоматических операций без подтверждения каждый раз.

3.6. Бумажник

Показывает только валюты (банкноты и монеты) и спецтокены Return. Ваучеры, сертификаты, платёжные/партнёрские ссылки — в отдельной вкладке «Инструменты».

Часть 1 — обзор балансов:

USD: 560.23
EUR: 100
TWD: 2 000
JPY: 100 000 000
Общий баланс (USD-эквивалент): 1 446.23

Сумма обеспечения в BTC не показывается — балансы FBTC-кошельков скрыты по архитектуре §2.4. Реальное обеспечение — лотерея до момента погашения.

Список бо́н. Сортировка по дате получения / номиналу / валюте. У каждой строки:

Картинка (открывается всплывающим при клике на строку, не на чекбокс).
Иконка ℹ — открывает: адрес отправителя, дату, код отправки, хэш транзакции.
Чекбокс выбора для пакетных операций.

Поиск отправителя — вверху справа: введи адрес или код отправки → подсветятся все бо́ны от этого отправителя.

Часть 2 — «Просмотр выбранного»:

Валюта/Номинал	Кол-во	Список
USD 20	1	VM00000001
USD 50	3	AA00000034, RE00034802, SS00000012
TWD 500	2	ER00000230, VM00000098

Итого: USD 170, TWD 1 000

Действия: Отправить / Разменять / Погасить. Размен возможен только в рамках одной валюты.

3.7. Сценарии

Отправить. Поля: адрес получателя + кнопка 0x (адресная книга), чекбокс Скрытно (через Обычный сертификат — встроенный криптомиксер), необязательный код подтверждения (до 6 знаков, без учёта регистра — для поиска получателем нужного перевода). Подтверждение → транзакция бесплатна → результат «Транзакция завершена успешно». Приватконтент перешифровывается с pubKey отправителя на pubKey получателя автоматически.

Разменять. Обмен крупной бо́ны на пакет мелких или наоборот. Контракт сжигает исходные NFT и минтит новые с эквивалентным суммарным обеспечением. Размен не раскрывает обеспечение конкретной исходной бо́ны.

Погасить. Подтверждение → автопогашение через FROST 6/8 (см. §4.4) → сводка выпущенных Return:

USD20   →  Return 5J1ghN5
USD50   →  Return wrQQ3ma
USD50   →  Return OTw/znl
TWD500  →  Return bSZukB4

Подсказка: «Рекомендуем сразу перевести средства с этих адресов на свой постоянный BTC-кошелёк.»

Купить:

Выбор валют из 14: USD, EUR, GBP, AUD, CAD, CHF, DKK, FKP, JPY, NOK, NZD, SEK, TWD, BTC + псевдовалюта KOD для регистрации Наставника (см. §8).
Выбор номиналов и количеств. Мелочь выделяется синим. По кнопке «Посчитать» — итог по валютам и сумма BTC.
Заказ с номером #[ДеньМесяцМинута]-[Код РКЦ]. У Наставника — бонус 2% и опция «Другой адрес получателя».
Оплата: Контракт через FROST генерирует одноразовый peg-in адрес multisig:

«Перечислите 0.01455 BTC на адрес bc1q.... После N подтверждений в Bitcoin партия выпустится автоматически.» Варианты: самостоятельно (с помощью встроенной справки по обменникам) или через РКЦ-обменник, если РКЦ предоставляет услугу. Срок действия заявки не ограничен.
История заявок: 3 последних (статусы no payment / done, кнопка Delete для неоплаченных).

3.8. Вкладка «Доверие»

Один клик — пользователь видит:

Подпись Контракта на каждой его бо́не валидна.
Multisig BTC содержит достаточно средств (баланс на blockchain.com).
ZK-доказательство покрытия валидно за последний блок.
Версия смарт-контракта совпадает с публичным аудитом (reproducible build).
В коде нет функций, которые могут произвольно тронуть его кошелёк.

3.9. Технические правила расчёта (для разработчиков)

Правило	Что
Не округлять BTC	при расчёте стоимости 1 бо́ны в BTC берём 8 знаков после запятой (1 satoshi = 0.00000001 BTC), без округления — иначе на больших партиях накопятся убытки
Зафиксировать раскладку при заказе	курс BTC через час будет другой; раскладка по бо́нам пишется сразу при формировании заказа
Допустимая погрешность ±2%	если клиент прислал чуть больше или меньше — разница компенсируется мелочью первой валюты заказа
Пакетный peg-in	партия копится до `Kopt = 10` адресов или `tmax = 90 мин`; при наборе 10 — до `Lmax = 1 МБ` или `tnorm = 20 мин` (что раньше)

4. Токенбоны: устройство, виды, жизненный цикл

4.1. Виды токенов в системе

Все токены — стандарт ERC-721, расширенный для FEEx (подпись Контракта в метаданных, ECIES-приватконтент, гашение).

Тип	Назначение	Откуда обеспечение
Банкнота	основная единица: USD20, EUR50, JPY10000, …	свой confidential FBTC-кошелёк, 80% от номинала при выпуске
Монета	мелкие номиналы (USD#0.01, EUR#0.05, …)	свой confidential FBTC-кошелёк, как у банкноты
Ваучер	токенизированный кошелёк на любую BTC-сумму, заранее заявленную владельцем	свой FBTC-кошелёк с открытой суммой (см. §7)
Ключ к ваучеру	парный токен для замороженных ваучеров	без обеспечения, утилитарный
Сертификат	пакет банкнот/монет («конверт»)	внутренние токены передаются Контракту, обеспечение наследуется
Ключ к сертификату	парный токен для замороженных сертификатов	без обеспечения
Return	спецтокен возврата при погашении: пара `(BTC-адрес, приваткей)` нового кошелька	сам не имеет, носит выплату
Спецтокены управления	голосующий, триггерный, информационный, аудит-токен (см. §9.3)	без обеспечения

4.2. Картинка

Картинка не хранится в блокчейне — генерируется на лету коллажем поверх графической матрицы (хранится в IPFS как неизменяемый CID, зашит в смарт-контракт).

Элементы коллажа:

Серия + номер. У каждого РКЦ своя серия (AA, AB, …, при необходимости — кириллица). Номер — 8 знаков от 00000001, независимо от номинала.
Код РКЦ — первые 6 знаков адреса NFT-кошелька РКЦ-изготовителя.
Логотип NFT — слева у кода РКЦ.
Подпись автора коллажа — красная для базовых номиналов, синяя для мелочи.
Логотип Bitcoin — справа у номера, указывает на привязку к BTC-обеспечению.

Адрес confidential-кошелька на картинке не печатается — он скрыт по архитектуре §2.4. Подлинность подтверждается криптографической подписью Контракта в метаданных, а не «адресом на банкноте».

Алгоритм печати

Используется convert из ImageMagick. На каждую валюту — две директории: матрицы + превьюшки для бумажника. Файл координат: {KodValute}_prn.bd.

# Координата 1 — серия и номер (зелёный для банкнот, бордовый для монет)
convert {FileInput} -font Verdana -fill #336633 -pointsize 20 -weight 800 \
  -annotate {Koordinata1} "{SeriaNum}" prn1.png

# Координата 2 — код РКЦ (красный, одинаково для всех)
convert prn1.png -font Arial -fill #C91203 -pointsize 14 -weight 900 \
  -annotate {Koordinata2} "{KodRKC}" prn2.png

Размер итоговой картинки ≈ 500 КБ. Версия алгоритма зафиксирована в коде Контракта — старые бо́ны рендерятся всегда той версией, в которой были выпущены.

4.3. Метаданные токена

Базовый номинал (банкнота / крупная монета)

Имя: [Код валюты+номинал] [Серия+номер] [Код РКЦ] — пример USD20 VM00000001 38D24A.
Описание (публично): [Серия+номер];[Код валюты];[Номинал];[Адрес РКЦ];[Подпись Контракта]
- Пример: VM00000001;USD;20;0x38D24A...8735FD0;0xa3f4...e9b1
Приватконтент (зашифрован ECIES публичным ключом владельца): только IDiw (32-байтовый идентификатор для поиска привязанного FBTC-кошелька в Threshold-ElGamal реестре Контракта).

Мелочь (банкнота/монета < $20)

Те же поля, отличия в формате имени и оформлении картинки:

Имя: [Код валюты#Номинал.NN] [Серия+Номер] — например USD#0.01 BM00000001.
Между серией и номером — решётка (AA#00000000 вместо пробела).
Подпись автора коллажа — синяя, серия+номер монет — бордовые.
В остальном — обычная NFT-бо́на со своим confidential FBTC-кошельком.

Упразднено по сравнению с книгой: агрегированный страховой фонд для мелочи, обязательное изготовление пакетами ≥$20, запрет прямого погашения, реестр валидной мелочи. В новой архитектуре каждая мелкая бо́на работает по тем же правилам, что и крупная — confidential-кошелёк, ZK-proof покрытия, FROST для подписи. Никаких особых правил.

Что зафиксировано в каждой бо́не и не меняется

Подпись Контракта (Schnorr через FROST 6/8) — невозможно подделать без 6 Судей.
Версия протокола выпуска (protocolVersion) — бо́на v1 всегда обрабатывается по правилам v1.
Все остальные публичные поля.

4.4. Операции с бо́ной — детали NFT-стороны

Полный системный жизненный цикл (peg-in/peg-out, mixing, доли BTC) — в §2.3 и §2.5. Здесь — только NFT-специфика.

Передача А→Б. МП у Васи через MetaMask локально расшифровывает приватконтент (ECIES приватключом Васи) и сразу шифрует тот же IDiw на pubKey Маши. Транзакция записывает в блокчейн нового владельца и обновлённый приватконтент. Контракт не трогает привязку к FBTC-кошельку. Если у Маши ещё нет pubKey в реестре — он восстанавливается из её первой подписи через ecrecover при первом подключении к МП.

Размен. Контракт сжигает исходные NFT, минтит новые с эквивалентным суммарным обеспечением; внутренние FBTC-кошельки переоформляются. Размен не раскрывает обеспечение конкретной исходной бо́ны.

Погашение. Контракт через Threshold ElGamal 6/8 расшифровывает привязку для конкретной бо́ны → через FROST 6/8 делает peg-out на свежий BTC-адрес → сжигает NFT-бо́ну → минтит спецтокен Return для владельца:

Имя: случайная подстрока + Return (например 6Y8dpT1 Return).
Описание: адрес BTC-транзакции + список погашенных бо́н.
Приватданные (ECIES под pubKey владельца): [Адрес BTC];[Приваткей].
Поведение: не имеет хождения; может быть только сожжён (отправлен на EMPTY000000000...).

Защита от потери Return: 24h эскроу перед окончательным burn NFT-бо́ны. Если клиент за 24h докажет, что не получил Return — перевыпуск с того же FBTC-кошелька. После 24h — burn окончательный.

Аудит-лог. В Контракте остаётся неизменяемая запись (timestamp, IDiw, burnTxHash, returnTokenHash) — без приваткеев и приватконтента.

5. Криптография

Все криптопримитивы — open-source, production-grade, проверенные. Никаких самодельных схем, никаких слабых мест по дизайну. Главное свойство всех ключевых схем: ни один приватный ключ не существует целиком ни на одном устройстве.

5.1. Сводка применяемых протоколов

Задача	Протокол	Готовая библиотека
Шифрование приватконтента бо́ны для передачи между владельцами	ECIES на secp256k1	стандартные ECIES-библиотеки
Подпись операций Контракта (peg-out BTC, mixing, минтинг, голосования)	FROST 6/8 + DKG на secp256k1	`zcash/frost` (Rust), ZF FROST RFC
Расшифровка приватных таблиц Контракта (привязка `IDiw → FBTC-кошелёк`, реестр стейка)	Threshold ElGamal 6/8 + DKG	`taurusgroup/multi-party-sig`, `threshold-crypto`
Скрытие балансов FBTC в нашем сайдчейне	Pedersen commitments + Bulletproofs (Confidential Transactions)	`secp256k1-zkp` от Blockstream
Хранение долей Судей (спецтокены с долями FROST/ElGamal)	приватконтент токенов, ECIES на pubKey Судьи	стандартные ECIES
Антибот-проверка (один человек — одна личность, без раскрытия имени)	Proof-of-Personhood	World ID, Anon Aadhaar

5.2. ECIES — шифрование приватконтента и передача бо́н

Приватконтент NFT-бо́ны (поле privateContent в блокчейне) зашифрован на публичный ключ текущего владельца через ECIES — гибридная схема AES + asymmetric:

K = random 256-bit                              # одноразовый AES-ключ
cipher = AES-256-GCM(plain, K)                  # шифруем содержимое
enc_K  = ECIES_encrypt(K, pubKey_owner)         # шифруем K на pubKey владельца
privateContent = (enc_K, cipher)                # пара уходит в NFT

Внутри plain лежит только IDiw — 32-байтовый идентификатор для поиска привязанного FBTC-кошелька в Threshold-ElGamal реестре Контракта. Самого адреса и баланса в приватконтенте нет.

Передача А→Б. МП у Васи через MetaMask локально расшифровывает privateContent (приваткей не покидает кошелёк) → шифрует тот же IDiw заново на pubKey Маши → транзакция записывает в блокчейн нового владельца и новый privateContent. Вася после этого расшифровать не может — старый шифр заменён.

Получение pubKey нового пользователя. Адрес Ethereum = keccak256(pubKey)[12:] (необратимый хэш), из адреса pubKey напрямую не достать. При первом подключении к МП пользователь подписывает «приветственное сообщение» → из подписи ecrecover восстанавливает pubKey → записывает в реестр Контракта-1. Дальше любой шифрует приватконтент на этот pubKey.

Что не может злодей: прочитать приваткей Васи или Маши (он в MetaMask, не в блокчейне), расшифровать чужой приватконтент (зашифрован на pubKey владельца), подменить получателя при передаче (транзакция подписана отправителем), подобрать AES-ключ (256 бит).

5.3. FROST 6/8 — пороговая подпись Шнорра

Используется для всех подписей, выполняемых от имени Контракта: peg-out BTC из multisig, ежемесячный confidential-mix, минтинг новых партий, голосования Судей.

Принцип. Каждый из 8 Судей держит свою долю приваткея, полученную через DKG (Distributed Key Generation). Полный приваткей никогда не существует целиком ни на одном устройстве — даже на этапе генерации.

Подпись (2 раунда):

Координатор объявляет операцию. 6 из 8 Судей публикуют свои nonce-commitments.
Каждый из этих 6 Судей локально на своём устройстве вычисляет частичную подпись своей долей.
Частичные подписи математически складываются в обычную подпись Шнорра, валидную против общего публичного ключа группы.

Внешне результат неотличим от подписи одиночного владельца — это даёт приватность (никто не знает, кто из Судей подписал) и совместимость с Bitcoin Taproot.

Защита от компрометации:

Утечка 1–5 долей — не угроза; <6 долей математически не дают ключ.
Принуждение 6 Судей в разных юрисдикциях — требует одновременной атаки на 6 человек в 6 странах.
Атака на координатор — он не имеет своей доли, только агрегирует готовые частичные результаты.

Опкод подписи Шнорра (математическая база FROST для проверки):

y = x·G                        # публичный ключ
r = k·G  (k — nonce)           # commitment
e = H(M ‖ r)                   # challenge
s = k − x·e   (mod q)          # response
подпись: (e, s);   проверка: r' = s·G + e·y;  OK если H(M ‖ r') == e

⚠ Уникальность nonce критична — повторный nonce раскрывает приваткей.

5.4. Threshold ElGamal 6/8 — пороговая расшифровка

Используется для приватных данных, которыми владеет Контракт ЕАП (а не пользователь): зашифрованная таблица IDiw → FBTC-адрес, реестр стейка, watchdog-логи.

Принцип. Тот же DKG генерирует пороговый ключ. Зашифровать может кто угодно (есть общий публичный ключ). Расшифровать — только при участии 6 из 8 Судей.

Расшифровка:

6 Судей делают частичную расшифровку ciphertext своими долями локально.
Координатор объединяет частичные результаты → получает открытый текст.
Сами доли не покидают Судей; координатор не видит ни доли, ни приватный ключ целиком.

Зачем не FROST. FROST умеет только подписывать. Для расшифровки нужен отдельный пороговый протокол — Threshold ElGamal.

5.5. Pedersen commitments + Bulletproofs — скрытые балансы FBTC

Используется для Confidential Transactions внутри блокчейна FEEx: на confidential-кошельках FBTC балансы физически невидимы для внешнего наблюдателя.

Pedersen commitment к сумме v имеет вид C = v·G + r·H, где r — случайный «ослепляющий фактор», G, H — генераторы кривой. Снаружи видно только C (хэш-подобное обязательство), сама сумма скрыта. Но коммитменты гомоморфны: C(a) + C(b) = C(a+b) — можно складывать суммы, не раскрывая их.
Bulletproofs — компактные zero-knowledge доказательства, что зашифрованная сумма попадает в допустимый диапазон (v ≥ 0, v < 2^64). Без них можно было бы «спрятать» отрицательную сумму и нарушить инварианты.

Что это даёт FEEx:

На confidential-кошельках FBTC балансы скрыты.
Mixing проверяемо сохраняет общую сумму (через гомоморфное свойство).
ZK-доказательство покрытия сумма_FBTC ≥ долг_по_бо́нам публикуется каждый блок.

5.6. DKG — генерация ключей без доверенного центра

Все ключевые схемы (FROST, Threshold ElGamal, multisig BTC) генерируются через Distributed Key Generation:

8 Судей одновременно запускают протокол.
Серия математических обменов сообщениями.
На выходе: каждый имеет свою долю; общий публичный ключ известен всем; полный приватный ключ не существовал ни на одном устройстве ни на одном этапе.

DKG-церемония публична, любой может её верифицировать.

Resharing. При расширении состава Судей (с 8 до 15–21 или замене скомпрометированного) DKG позволяет перевыпустить доли без смены общего ключа — то есть всё, что было зашифровано/подписано старым составом, остаётся валидным.

5.7. Сводка ключей Системы

Ключ	Где живёт	Зачем
Приваткей пользователя (MetaMask и т.п.)	устройство пользователя	подписывает транзакции, расшифровывает приватконтент своих бо́н
Публичный ключ пользователя	реестр Контракта-1 (после первой подписи)	для шифрования приватконтента при передаче бо́ны этому пользователю
ГСК — Главный Секретный Ключ Контракта ЕАП (FROST)	доли у 8 Судей через DKG	подпись всех операций Контракта (peg-out, mixing, минт)
Threshold-ElGamal ключ	доли у тех же 8 Судей через DKG	расшифровка приватных таблиц Контракта
Multisig 6/8 BTC	те же доли, контроль над BTC в публичной сети Bitcoin	хранение реального обеспечения
Резервные мастеркеи (20–30 шт.)	те же 8 Судей через FROST	быстрая замена ГСК при компрометации
Долевые спецтокены Судей	в кошельках Судей, приватконтент ECIES	физические носители долей FROST/ElGamal

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

6. Главный и резервные ключи Системы

6.1. Состав 8 Судей

Сторона	Кто	Сколько
Автор	автор + 3 его Наблюдателя	4
Разработчик	разработчик + 3 его Наблюдателя	4
Итого		8

Наблюдатели — внешние доверенные лица с публичной репутацией: криптоэксперты, юристы из юрисдикций запуска, представители крупных РКЦ, известные в сообществе аудиторы. Они следят за порядочностью автора и разработчика; у каждой стороны — своя группа.

Зачем 3+3. Чтобы автор и разработчик не могли сговориться: у каждого своя группа Наблюдателей. Скомпрометированную сторону блокируют её же Наблюдатели.

Почему порог 6/8. Любая операция требует минимум 4 Наблюдателей и обязательно включает обе стороны:

5/8 → автор + разработчик + 3 одной стороны = 5; одна сторона может управлять без другой → не годится.
7/8 → почти единогласие, один «потерявшийся» блокирует всё.
6/8 — золотая середина. Невозможно собрать 6 без участия Наблюдателей обеих сторон.

6.2. ГСК — Главный Секретный Ключ Контракта ЕАП

ГСК — это пороговый ключ Контракта ЕАП, через который подписываются все операции Контракта (peg-out BTC, mixing, минт, голосования) и расшифровываются приватные таблицы.

Архитектура: FROST 6/8 для подписи + Threshold ElGamal 6/8 для расшифровки + DKG для генерации (см. §5). Полный приваткей не существует целиком ни на одном устройстве — даже на этапе генерации. Каждый Судья хранит только свою долю.

Долевые спецтокены Судей — носители долей FROST/ElGamal:

Лежат у Судей на их кошельках в нашем блокчейне.
Приватконтент токена зашифрован ECIES на pubKey Судьи.
Используются Судьёй для генерации частичных подписей / частичных расшифровок при участии в операциях Контракта.

Скрытие адресов Судей (защита от «прижать оффлайн»):

Долевые спецтокены хранятся не на «постоянных» адресах Судей, а через обёрточные сертификаты Контракта — Контракт раздаёт ключи к сертификатам Судьям. Снаружи видны только адреса Контракта и кучи сертификатов — кто чей, не определить.
Дополнительно — decoy-токены: 100 фейковых спецтокенов с фейковыми долями на случайных адресах. Атакующий не отличит настоящие.
Периодическая ротация адресов Судей через DKG-resharing.

6.3. Резервные мастеркеи

20–30 запасных пороговых ключей, сгенерированных через FROST + DKG. Назначение — мгновенная замена ГСК при компрометации, без необходимости проводить новую DKG-церемонию (которая требует часов).

Алгоритм замены:

Триггер «смена мастеркея» от любого Судьи через on-chain голосование с timelock 24h.
Контракт останавливает критичные операции и ждёт 8 часов на подтверждение от 6 из 8.
Если подтверждение получено — следующий резервный ключ в списке становится действующим, старый помечается скомпрометированным; перевыпуск всех долевых спецтокенов под новый ключ через DKG-resharing.
Если нет — триггер обнуляется. Повторный триггер этой темы — не ранее чем через неделю (cooldown против DoS).

Параметр	Значение
Количество резервных ключей	20–30
Схема каждого	FROST 6/8 + DKG
Timelock на триггер	24 часа
Срок ожидания подтверждения	8 часов
Cooldown между триггерами	1 неделя

6.4. Расширение и ротация состава Судей

DKG-resharing позволяет:

Добавлять новых Судей при росте системы (план: 8 → 15–21 при зрелости).
Заменять скомпрометированного Судью без смены ГСК.
Периодически ротировать доли (защита от утечки старых долей).

Что не теряется при resharing: общий публичный ключ группы — все ранее зашифрованные данные остаются расшифровываемыми, все ранее подписанные — валидными.

6.5. Социальное восстановление (для пользователей)

Не для ГСК, а для пользовательских кошельков. Через Account Abstraction владелец задаёт «гарданов» (доверенных лиц) — при утере приваткея большинство гарданов может восстановить доступ к кошельку без раскрытия каких-либо приватных данных.

7. Инструменты: платежная ссылка, ваучеры, сертификаты

Помимо собственно бо́н (валют), система предоставляет три инструмента: платежная ссылка, ваучеры, сертификаты. Все живут в нашем confidential-сайдчейне, используют те же FROST 6/8 + Threshold ElGamal + ECIES, что и бо́ны.

7.1. Сводка инструментов

Инструмент	Назначение	Стоимость
Платежная ссылка	оплата фиксированной суммы на заданный кошелёк одним кликом по ссылке на любом сайте	бесплатно
Эксклюзивная платежная ссылка	то же, но оплачивается один раз — для штучной анонимной продажи	бесплатно
Партнёрская ссылка	привод клиента в Систему, идёт без очереди коммерческой справедливости на МП конкретного РКЦ	бесплатно
Обычный ваучер	токенизированный кошелёк на любую BTC-сумму, заранее заявленную владельцем	$2 (50/50 РКЦ / Системе)
Замороженный ваучер	ваучер + парный токен-ключ; нужны оба для погашения. Для залогов в сделках без посредника	бесплатно из обычного
Замороженный на период	то же, но с автовозвратом владельцу ключа через 1ч / 1д / 3д / 1нед / 1мес	бесплатно
Красный ваучер	анонимный накопительный счёт с паролем; передача через клонирование (встроенный криптомиксер)	$2 (50/50)
Сертификат	пакет банкнот/монет (аналог конверта с деньгами или zip-архива)	бесплатно
Замороженный сертификат	сертификат + ключ; распаковка/погашение требует обоих	бесплатно

7.2. Платежная ссылка

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

Создание (продавцом): в МП → «Инструменты → Платежная ссылка» → адрес получателя, валюта и сумма → опционально галочка Exclusive (одноразовая) → Создать. МП выдаёт URL и кнопку «Скопировать».

В URL зашифровано через ECIES (ключ — публичный ключ Контракта-1, не XOR; любое МП Системы может расшифровать):

адрес кошелька продавца;
валюта и сумма;
(для Exclusive) идентификатор уникальности.

Оплата (покупателем): клик по ссылке → его МП декодирует параметры → автоматически открывает в подключённом кошельке подпись транзакции на нужную сумму → после подтверждения средства уходят продавцу. Если ссылка Exclusive — она помечается оплаченной и блокируется в реестре Контракта.

Оплата несколькими бо́нами. МП автоматически подбирает оптимальный набор бо́н из Бумажника покупателя на нужную сумму. Если точной суммы нет — берёт ближайшую большую и доплачивает мелочью (или предлагает докупить недостающую мелочь у РКЦ). Точная сумма достижима почти всегда за счёт мелочи до $0.01.

7.3. Ваучеры

Ваучер — токенизированный FBTC-кошелёк с открытой суммой. Главное отличие от бо́н: у ваучера сумма известна владельцу и публикуется в Описании — это часть UX-сути («положил $100 — ваучер на $100»). Поэтому ваучеры не участвуют в ежемесячном mixing бо́н — у них фиксированная сумма по дизайну.

7.3.1. Обычный ваучер

Имя: BTC 5J1ghN5 (серия VCHR + первые 7 знаков идентификатора FBTC-кошелька).
Описание (публично): BTC5J1ghN5;[Адрес РКЦ];[Подпись Контракта];[Сумма FBTC].
Приватконтент (ECIES под pubKey владельца): IDiw для поиска привязанного FBTC-кошелька.

Передача и погашение — как у бо́н: при передаче приватконтент перешифровывается на нового владельца; при погашении Контракт через FROST 6/8 делает peg-out и выдаёт спецтокен Return.

7.3.2. Замороженный ваучер (F)

Ваучер + парный токен-ключ в том же кошельке. Для погашения требуются оба:

ключ и ваучер находятся сейчас в одном кошельке;
ключ был изготовлен в кошельке, где на тот момент находился сам ваучер (привязка фиксируется Контрактом при заморозке).

Передача ЗВ — свободна (с кодом доставки), но без ключа погасить нельзя. Если ключ утерян — средства заперты навсегда (как любой BTC-кошелёк с утерянным паролем).

Токен-ключ:

Серия VKey, имя — случайный BASE64 (10 знаков), картинка одна для всех («золотой ключик»).
Описание: For user only.
Приватконтент: [номер ключа];[номер ваучера].

Применение: залог в сделке без посредника-банка. Покупатель отдаёт ЗВ → продавец видит обеспечение → после поставки покупатель отправляет ключ → продавец гасит. Если сделка сорвалась — продавец возвращает ЗВ.

Мультиключ к ЗВ. Можно сделать несколько ключей по схеме Threshold ElGamal — погашение требует k из n ключей. Для совместного владения, корпоративных счетов и т.п.

7.3.3. Замороженный на период (F-TIME)

То же что ЗВ, но при заморозке выбирается период: 1ч / 1д / 3д / 1нед / 1мес. По истечении — единократная проверка Контрактом:

ключ и ваучер у одного владельца → всё ОК, ваучер остаётся как есть;
в разных кошельках → Контракт автоматически возвращает ваучер владельцу ключа.

Алгоритм возврата (блокчейн не допускает принудительный перенос без подписи владельца): при заморозке Контракт сохраняет «копию данных» ваучера в зашифрованной таблице. По истечении периода:

если связка восстановилась — копия удаляется;
если нет — Контракт минтит новую копию ваучера на адрес владельца ключа (имя VCHR XXX F-TIME/COPY). Оригинал остаётся «мусором» в кошельке несостоявшегося покупателя.

Применение: покупатель защищён от срыва сделки — если продавец не доставил, ваучер вернётся автоматически.

7.3.4. Красный ваучер (R) — анонимный накопительный счёт

Самый приватный инструмент Системы. Защищён паролем, передача через клонирование (встроенный криптомиксер).

В публичных данных — только серия и номер. Описание: For user only. Сумма не указывается.
BTC-адрес ваучера не виден никому, включая владельца до момента погашения.
Привязка (красный ваучер → FBTC-кошелёк) зашифрована Threshold ElGamal у Контракта, защищена паролем владельца.

Пароль. Задаётся владельцем при создании, вводится 2 раза. Контракт хранит только хэш. После 5 неудачных попыток — таймаут 2 часа на этот кошелёк (защита от брутфорса).

Накопительный режим. Сумма плавающая. Владелец может вводить платёжки [BTC-адрес назначения, сумма] → Контракт через FROST подписывает peg-out, отправляет средства; сдача возвращается обратно на FBTC-кошелёк ваучера; сам токен остаётся у владельца. В публичной сети Bitcoin виден только адрес multisig Контракта — реальная связь с КВ скрыта.

Передача через клонирование. При передаче А→Б МП Васи (после ввода пароля) запрашивает Контракт «выпусти новый КВ с теми же привязками для Маши» → Контракт через FROST минтит новый КВ с другим номером и привязкой к тому же FBTC-кошельку → старый КВ Васи сжигается. Снаружи нельзя проследить связь между старым и новым КВ — это функция криптомиксера.

7.4. Сертификаты

Сертификат — пакет бо́н и/или монет, аналог конверта с деньгами или zip-архива. Делается бесплатно по запросу пользователя.

Имя: CRT 3UysaM4 (серия CRTF).
Описание (публично): список содержимого через ; — VM00000001;AA00000034;RE00034802;SS00000012;....
В МП по иконке справа от строки сертификата открывается таблица содержимого с подсчётом сальдо по валютам.

Жизненный цикл:

Изготовление: входящие бо́ны передаются на адрес Контракта; их FBTC-привязки наследует сертификат.
Передача: сертификат ходит как один NFT; внутренние бо́ны остаются у Контракта.
Распаковка: Контракт возвращает все бо́ны на кошелёк владельца, сертификат сжигается.
Погашение: Контракт сразу гасит все бо́ны внутри (FROST + peg-out) и выдаёт владельцу пакет спецтокенов Return.

7.4.1. Замороженный сертификат

Сертификат + парный ключ. Для распаковки или погашения нужны оба, как у замороженного ваучера. Используется для безопасной передачи крупных сумм с гарантией.

7.4.2. Скрытные платежи (встроенный криптомиксер)

В Бумажнике при отправке бо́н — галочка «Скрытно». МП сначала упаковывает выбранные бо́ны в Обычный сертификат (без ключа) и отправляет уже его. В публичных метаданных сертификатов нет привязки к конкретному пользователю — наблюдатель блокчейна видит только, что бо́ны ушли Контракту, но не получение их адресатом.

7.5. Изготовление ваучеров — экран в МП

Заполнение формы (на примере USD, 5 ваучеров):

Поле	Значение
Валюта	USD
Количество ваучеров	5
Сумма каждого ($)	18.60
Итого к оплате (BTC)	`0.003263`
Из них BTC-комиссия mainnet (17 sat/vbyte)	`0.00023137`
Эффективная сумма на ваучер (BTC)	`0.00060632`

Расчёт: (0.003263 − 0.00023137) / 5 ≈ 0.00060632 (8 знаков, округление вверх).

При нажатии Создать заказ уходит в Контракт; после подтверждения BTC-перевода ваучеры выпускаются пакетной транзакцией и приходят в кошелёк владельца. К каждой партии можно сразу применить заморозку (выпуск парного ключа).

8. Наставник (реферальная программа)

Наставник — пользователь, который привёл в Систему другого клиента. Получает 2% дисконт от своих покупок и опцию отправлять купленные бо́ны с адреса Контракта (не засвечивая свой кошелёк).

8.1. Условия получения статуса

Статус Наставника назначается автоматически при выполнении трёх условий:

У пользователя есть proof-of-personhood (World ID / Anon Aadhaar) — один человек = один Наставник, никаких ботов.
Совершена покупка через партнёрскую ссылку активного Наставника или первый заказ пользователя оформлен через РКЦ с пометкой «приведён мной».
Минимальная сумма первого заказа — $100 в эквиваленте.

После завершения первого заказа Контракт записывает связь (новый_клиент → Наставник) в реестр Контракта-1. Пара становится постоянной.

8.2. Бонус для Наставника

2% дисконт от итоговой суммы каждого его собственного заказа на покупку бо́н (бессрочно).
Опция «Другой адрес получателя» при покупке — изготовленные бо́ны отправляются с адреса Контракта на любой указанный адрес. Полезно для подарков и приватных платежей: получатель не видит, кто именно купил бо́ны.

8.3. Партнёрская ссылка Наставника

В МП Наставник создаёт партнёрскую ссылку (раздел Инструменты, см. §7.1):

Любой клиент по этой ссылке попадает на МП выбранного Наставником РКЦ напрямую, без очереди коммерческой справедливости (см. §3.4).
При первой покупке клиента по этой ссылке Контракт автоматически фиксирует Наставника.

8.4. Защита от накруток

Один человек — один Наставник через proof-of-personhood. Без этого нельзя зарегистрироваться.
Пара (клиент → Наставник) фиксируется при первом заказе и неизменна — нельзя переписывать кому-то «своих» клиентов задним числом.
Антифрод-эвристика Контракта (см. §2 → MVIP) ловит цепочки фиктивных привлечений: массовые регистрации с одного источника, кошельки без активности после первой покупки и т.п.

8.5. Что меняется в МП у Наставника

В разделе «Инструменты» появляется «Партнёрская ссылка» (создание/просмотр/удаление).
В сценарии «Купить» (см. §3.7) автоматически применяется 2% дисконт и появляется опция «Другой адрес получателя».
В разделе «Контакты» — список приведённых клиентов (без личных данных, только адреса кошельков и даты).

9. Управление системой и спецтокены управления

Управление FEEx — on-chain через Контракт управления, без скрытых рычагов и админ-кнопок. Любое действие, влияющее на Систему, проходит через голосование Судей, имеет timelock и публично виден в блокчейне.

9.1. Кто и что может

Роль	Что может
Любой Судья (8 шт.)	Инициировать предложение, голосовать «за/против», запускать триггер смены резервного ключа (см. §6.3)
Совет Управляющих (6 из 8)	Утверждать обновления контрактов, добавлять/исключать РКЦ, менять параметры (КПДС, лимиты MVIP, состав партий и т.п.)
Все 8 Судей единогласно	Изменять «прибитые» правила: формула 80% обеспечения, право погашения, правила выпуска бо́н, состав Судей
РКЦ	Минтить новые партии бо́н (whitelist в смарт-контракте), управлять своим МП и НКЦ
Watchdog-узлы	Мониторить Контракт, публиковать алерты при аномалиях; голоса не имеют
Пользователи	Видеть все предложения, голосования, аудит-лог (read-only)

9.2. Архитектура голосований

Голосование = транзакция в нашем блокчейне через Контракт управления. Подпись каждого Судьи — частичная подпись FROST (см. §5.3). Снаружи видна только агрегированная подпись Шнорра — кто конкретно подписал, не различить (защита Судей).

Параметры порогов:

Тип решения	Порог	Timelock	Cooldown
Обычное (параметры, добавление РКЦ)	6/8	7 дней	—
Обновление логики смарт-контрактов	6/8	30 дней	—
Триггер смены резервного мастеркея	6/8	24 часа + 8 часов на сбор подписей	1 неделя
Право погашения бо́н, формула 80%, состав Судей	8/8	30 дней	—

Timelock — окно между принятием решения и его исполнением. За это время любой пользователь может погасить свои бо́ны, если не согласен с изменением. Это часть гарантии «no admin keys» (см. §14).

9.3. Спецтокены управления

Это утилитарные NFT, через которые Контракт управления взаимодействует с Судьями и Системой. Не имеют обеспечения, не передаются, не торгуются.

Тип	Что делает
Голосующий токен	Один в собственности каждого Судьи. Используется для подачи голоса в текущем опросе — содержит частичную FROST-подпись Судьи.
Триггерный токен	Краткоживущий NFT, инициирующий процедуру (смену ключа, аварийный peg-out). Сжигается после исполнения или отказа.
Информационный токен	Уведомления Судьям (требуется ваш голос / собран кворум / аномалия от watchdog). Чисто почтовый канал внутри блокчейна.
Аудит-токен	Запись о каждой исполненной операции Контракта (хэш, timestamp, тип). Неизменяемый, навсегда. Любой может прочитать.

9.4. Аварийные процедуры

Сценарий	Кто запускает	Что происходит
Компрометация ГСК	Любой Судья	Триггер смены резервного мастеркея (см. §6.3)
Аномалия в multisig BTC (несанкционированная попытка вывода)	Watchdog-узлы → автоматический алерт всем Судьям	Голосование 6/8 о приостановке операций; в норме срабатывает за 1–2 часа
Подозрительный РКЦ (фиктивные минты, накрутка)	Любой Судья или watchdog	Голосование 6/8 об исключении из реестра РКЦ; конфискация неоплаченного НКЦ-баланса
Критическая уязвимость в коде (найдена через bug bounty)	Любой Судья	Аварийное обновление 6/8 с сокращённым timelock 24 часа + публичный анонс

9.5. Что зафиксировано архитектурно (нельзя изменить даже 8/8 без timelock 30д)

Невозможность функций pause(address) / freeze(address) / mint без обеспечения / burn чужого — этих функций просто нет в коде.
Право пользователя погасить свою бо́ну.
Формула 80% реального обеспечения при выпуске.
Open-source код, reproducible builds.

Все управляющие действия — публичны и записаны в неизменяемый аудит-лог. Никаких «решений в кабинете», только on-chain голосования.

10. Юрисдикции и стратегия запуска

10.1. Многослойная стратегия

Слой	Юрисдикция	Зачем
Главный фонд + протокол	Лихтенштейн или Швейцария (Цуг)	юридическая защита от взлома регулятором, банковские отношения
DAO Совета Управляющих	Маршалловы Острова (RMI)	DAO = юрлицо с 2022, $5k на регистрацию
Резервная база	Сальвадор	BTC = legal tender, есть Bitcoin Office
Операционные РКЦ	ОАЭ Dubai (VARA), Сейшелы, Сингапур, Гибралтар	масштабирование по регионам

10.2. Почему такие юрисдикции

Лихтенштейн — в 2020 принят Token Container Model в законе: токенизация чего-угодно прямо легализована. Это идеальная база для FEEx, потому что токенбона юридически = digital token-container с активом-обеспечением.

Швейцария Цуг — Crypto Valley, понятная регуляция через FINMA, приличная репутация для банковских отношений. Дороже Лихтенштейна (от $30-100k на запуск + сопровождение).

Сальвадор — BTC legal tender с 2021, прецедент Volcano Bonds. Можно официально оформить «токенбоны = Bitcoin-derivative» без проблем с регулятором. Минусы: слабая банковская инфраструктура, политические риски.

Маршалловы Острова — DAO LLC признаются юрлицами (с 2022). $5k на регистрацию. Идеально для on-chain governance Совета Управляющих.

Дубай VARA — специальная регулирующая зона, понятный режим для Ближнего Востока.

10.3. О чём спорить с регулятором

Юридическая позиция FEEx: токенбона — не money, не security, а digital collectible с обеспечением.

Не money: нет общего эмитента, нет lender of last resort, нет обязательства peg к фиату (см. §2.4: бона = опцион на BTC).
Не security: Howey test проваливается — нет ожидания прибыли от усилий третьей стороны, нет общего предприятия.
Это: bitcoin-based payment instrument (как paper wallets) + collectible (как gold-backed NFT).

Реалистичная оценка:

В Лихтенштейне/Сальвадоре: 80% шансов получить статус «unregulated digital asset».
В США без MSB-лицензии работать нельзя — поэтому американский рынок изначально не таргетим или работаем через KYC-РКЦ с лицензией.
ЕС: MiCA (Markets in Crypto-Assets) с 2024 — сложно, нужна e-money licence или CASP.
Россия, Китай, Иран и другие санкционные юрисдикции — РКЦ там не запускаем.

10.4. Стратегия «свободы»

Главный фонд + протокол → Лихтенштейн/Швейцария (защита от взлома регулятором).
DAO → Маршалловы Острова (защита автономности).
РКЦ → каждая страна, где это можно (масштабирование).
Если страна заблокирует своих РКЦ — остальные продолжат работать. Сеть защищена от одной юрисдикции.

11. Развёртывание и обновления (IPFS, апгрейды)

11.1. Слои архитектуры по обновляемости

Слой	Что	Как обновляется
Замороженное навсегда	графические матрицы, алгоритм печати, формула проверки подписи	CID в IPFS зашит в смарт-контракт; изменить нельзя; новые версии — только для новых бо́н
Версионируемое (на привязке к бо́не)	UI рендеринга, локализация, иконки	бо́на помнит `protocolVersion = N`; новые бо́ны рендерятся по новому, старые — по старому навсегда
Обновляемое через 6/8	главная страница, текст, дизайн, общие компоненты МП	IPNS под пороговым ключом 6/8 + timelock 7 дней + публичный анонс
Логика контрактов	смарт-контракты	Diamond Pattern (EIP-2535) или UUPS Proxy, через 6/8 голосование Судей и timelock 30 дней
Архитектурные инварианты	право погашения, формула 80% обеспечения, состав Судей	8/8 + timelock 30 дней — двойной замок (см. §9.5)

11.2. IPFS — варианты обновления сайта

IPNS (рекомендуется):

Стабильное «имя» вида ipns://k51q..., переключаемое на новый CID.
Управляет владелец IPNS-приваткея — но мы делаем его пороговым 6/8.
Любое обновление требует подписи 6 Судей.

DNSLink:

TXT-запись dnslink=/ipfs/QmXyz... в DNS.
Удобно: feex.app как привычное имя.
Минус: зависимость от DNS-провайдера, уязвим к юр-давлению.

Multi-gateway redundancy:

Сайт пинится на 5+ IPFS-провайдерах: Pinata, web3.storage, Filebase, ipfs-нодах самих РКЦ.
Если один провайдер упал/заблокирован — остальные работают.

Tor onion-mirror:

Параллельный доступ через .onion — антицензура, не требует HTTPS.

11.3. Что можно и что нельзя обновлять

Можно обновлять (через threshold + timelock):

UI/UX, тексты, стили, иконки.
Локализации.
Не критичная часть фронтенда МП.

Архитектурные инварианты — двойной замок 8/8 + timelock 30 дней (см. §9.5):

Право на погашение бо́ны.
Формула 80% обеспечения при выпуске.
Состав Судей.
Невозможность функций pause / freeze / mint без обеспечения / burn чужого.

11.4. Принцип честности к пользователям

Любое обновление логики — on-chain голосование Судей + timelock 30 дней + публичный анонс. За 30 дней любой пользователь может погасить свои бо́ны, если не согласен.
Старые CID никогда не удаляются — старая версия сайта/МП всегда доступна для проверки «не подменили ли».
Версия протокола зашита в каждой бо́не (protocolVersion) — выпустил $20-бо́ну в 2026, она через 100 лет рендерится и обрабатывается ровно так же.
Reproducible builds — бинарники нод и МП собираются детерминированно; любой может проверить, что в продакшене именно тот код, что опубликован.

12. Кошельки и подключение

12.1. Поддержка кошельков

Решение	Что
WalletConnect v2 + Web3Modal/RainbowKit	базовый коннектор: ~300 кошельков (MetaMask, Trust, Rainbow, Argent, Ledger Live, Coinbase Wallet, Phantom EVM)
EIP-1193 / EIP-6963	стандартные интерфейсы injected wallets — не требует кода под конкретный кошелёк
Нативный кошелёк FEEx	mobile + browser extension с интеграцией специфичных операций (платёжные ссылки в один клик, скрытные платежи, ваучеры). Отдельная разработка

12.2. Сертификаты и HTTPS

Все МП РКЦ работают на HTTPS — это требование secure-context браузеров для подключения кошельков. Параллельно — антицензурные альтернативы.

Канал	Как
HTTPS	Let's Encrypt (автообновление через certbot) на каждом РКЦ
Tor `.onion`	end-to-end шифрование встроено, HTTPS не нужен — антицензурный бэкап
IPFS Gateway	публичный gateway даёт HTTPS-доступ к нулевой странице IPFS

12.3. Многоканальный доступ — итог

Основной вход — нулевая страница в IPFS под threshold-IPNS 6/8 (см. §3.2).
Подключение кошелька — WalletConnect v2 + Web3Modal.
HTTPS на МП каждого РКЦ — Let's Encrypt.
Tor .onion-mirror — антицензурный канал.
IPFS gateway — резерв при блокировке DNS.
Нативный FEEx-кошелёк — отдельный продукт для максимального UX.

13. SDK и интеграции

13.1. Базовый SDK (приоритетно)

1. JavaScript / TypeScript SDK для веб-интеграций:

import { FEEx } from '@feex/sdk';
const feex = new FEEx({ rkc: 'https://rkc.example.com' });

// Создать платёжную ссылку
const link = await feex.createPaymentLink({
  amount: 20, currency: 'USD',
  returnUrl: 'https://shop.com/thanks',
  exclusive: true
});

// Слушать поступления
feex.onPayment((event) => {
  console.log('Получен платёж:', event.tokenIds);
});

2. Drop-in HTML-виджет для не-программистов:

<script src="https://cdn.feex.app/widget.js"></script>
<feex-pay amount="20" currency="USD" wallet="0x..."></feex-pay>

3. REST API через РКЦ:

POST /api/v1/payment-links — создать ссылку
GET /api/v1/balance/:address — баланс по бо́нам
POST /api/v1/withdraw — погашение
GET /api/v1/quote?from=USD&amount=100&to=BTC — текущий курс
POST /api/v1/voucher — выпуск ваучера
GET /api/v1/orders/:id — статус заказа

4. Готовые плагины:

WordPress (WooCommerce).
Shopify.
Magento / OpenCart.

13.2. Расширенный SDK

iOS / Android SDK — нативная интеграция в мобильные приложения (e-commerce, donate, micro-payments).
Smart contract templates — шаблоны для DeFi-интеграций: subscription contracts на платёжных ссылках, escrow на замороженных ваучерах.
CLI-tool для РКЦ: feex-cli mint, feex-cli backup, feex-cli stats.
Webhook system — для backend-интеграций (уведомления о платежах, погашениях).

13.3. Что отличает FEEx SDK

Платежи бесплатны для пользователя (нет газа на стороне юзера) → нет gas estimation, нет ошибок «недостаточно ETH».
Поддержка скрытных платежей через сертификаты-обёртки (один флаг hidden: true).
Поддержка залоговых платежей через замороженные ваучеры (escrow: { type: 'frozen', period: '1 day' }).
Multi-currency из коробки (14 валют).
Платёжные ссылки — одной строкой без серверной части у мерчанта.

14. Гарантии для держателей токенбон

«Bill of Rights» владельца бо́ны — обязательства Системы, защищённые архитектурно (не «доверьтесь нам», а «вот код, проверяйте»):

Под каждой бо́ной — индивидуальный confidential FBTC-кошелёк. Привязка зашифрована Threshold ElGamal у Контракта. Multisig BTC, под которым лежит реальное обеспечение всей системы, — публичный адрес: любой может проверить общий баланс на blockchain.com и сравнить с ZK-доказательством покрытия сумма_FBTC ≥ долг_по_бо́нам.
No admin keys. В смарт-контрактах нет функций pause/freeze(address)/mint без обеспечения/burn чужого. Никто не может заморозить ваш кошелёк или произвольно изменить баланс.
Право на погашение неотменяемо обновлением контракта. Изменение проверочной функции redeem(NFT) требует 8/8 голосов Судей + timelock 30 дней (двойной замок), вместо стандартных 6/8. Хотя бы один Судья из 8 может заблокировать удаление права погашения.
Версия алгоритма выпуска зашита в самой бо́не (protocolVersion). Бо́на v1 всегда обрабатывается правилами v1, даже если протокол обновится до v5.
Все изменения логики — публичные, с timelock 30 дней + on-chain голосованием Судей. За 30 дней любой пользователь может погасить свои бо́ны, если не согласен с изменением.
Старые версии сайта/МП всегда доступны в IPFS под прежними CID. Reproducible builds позволяют проверить, что в продакшене именно тот код, что опубликован.
При компрометации ГСК Система через 8 часов переключается на резервный мастеркей (см. §6.3) — холдеры не теряют доступ к своим бо́нам.
Юрисдикционная диверсификация. РКЦ распределены по странам. Блокировка в одной стране не останавливает Систему. Антицензурный вход через IPFS + Tor.
Открытый код и аудиты. Контракты, нода, МП, SDK — open-source. Публичные отчёты Trail of Bits / OpenZeppelin / Halborn. Bug bounty $50k–$1M. Формальная верификация критичных функций.
Прозрачность управления. Все голосования Судей on-chain, аудит-лог неизменяем, watchdog-узлы публикуют алерты при аномалиях. Никаких «решений в кабинете».

15. Открытые параметры

Решения, требующие финализации:

Лимит погашений в сутки одним адресом — какое значение?
VRF для случайной даты mixing — Chainlink VRF / собственная реализация на BLS / Schnorr-VRF?
Юр. лицо — Лихтенштейн или Швейцария (Цуг)?
Compliance-стратегия для ЕС (MiCA) — оформляться или не таргетить рынок ЕС?
DNS-домен — feex.app, feex.cash, feex.io, иное?
Pinning-сервисы для IPFS — какие из Pinata / web3.storage / Filebase / собственные ноды РКЦ?
Локализация МП — англ. + рус., или сразу больше языков?
Реализация Confidential Transactions — портировать secp256k1-zkp от Blockstream или писать с нуля?

Name		Name	Last commit message	Last commit date
Latest commit History 2 Commits
.gitignore		.gitignore
Dif.md		Dif.md
README.md		README.md
ReadmeOld.md		ReadmeOld.md

Folders and files

Latest commit

History

Repository files navigation