Efi.net / Efimerical Network

Статус документа

Этот документ является "живым" техническим описанием прототипа Efi.net (Efimerical Network) и обновляется по мере развития кода, протоколов и клиентских модулей. Версия v0.2 фиксирует текущую архитектурную концепцию и каркас ключевых механизмов; последующие версии будут дополняться примерами реализации, ссылками на код и уточнениями протоколов.

Changelog (кратко): v0.2 — уточнены принципы offline-first клиента, модель мнемонической фразы восстановления, двухуровневая экономика EFI/EGP, структура дашборда и управляемого доступа.

Концепция и Архитектура

Название проекта: Efi.net

Полное название сети: Efimerical Network (рабочий прототип)

Тип: Закрытая оверлейная сеть (overlay network), функционирующая как изолированная цифровая экосистема.

Сеть использует управляемое членство и протоколы допуска (инвайты/проверка), что позволяет контролировать рост и снижать автоматизацию/спам.

Ключевая инновация: Полное отсутствие комиссий за внутренние переводы, обеспеченное двухуровневой монетарной системой (EFI/EGP).

Стратегия развития: Поэтапный рефакторинг критических модулей на язык Rust для обеспечения максимальной производительности и безопасности.

Экономическая модель (Токеномика)

Базовая единица: Efimerium EFI (ценная/учетная единица).

Расчетная единица: Efimerium Golden Part EGP (основная валюта для транзакций). Курс фиксирован: 1 EFI = 10 000 EGP.

Принцип операций: Все транзакции внутри экосистемы выполняются с нулевой комиссией. Вместо классических моделей консенсуса, основанных на соревновании за вычислительные ресурсы или долю капитала, Efimerical Network использует модель распределения, основанную на вкладе в жизнеспособность экосистемы.

Начисление EGP осуществляется за поддержание активности сети, участие в её развитии и расширении, включая:

• поддержание собственных узлов (nodes);
• генерацию и валидацию сетевых состояний;
• привлечение новых участников через систему инвайтов;
• развитие пользовательских точек входа (points of presence);
• участие в реферальных и социальных механизмах роста.

Такая модель устраняет необходимость транзакционных комиссий и переводит экономическую мотивацию с обработки отдельных операций на устойчивое развитие всей экосистемы.

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

Функциональные модули экосистемы (Встроенные сервисы)

Экосистема интегрирует в себе:

NFT-инфраструктура

Используется не только для цифрового искусства, но и как основа для создания блогов, витрин магазинов и мини-приложений (dApps), сертификатов на право владения, игровых предметов, характеристик аккаунтов, персонажей.

// TODO: paste NFT structure code here

Коммуникация

Встроенный мессенджер IUCom для пользовательского взаимодействия.

Социальная динамика

• Система приглашений (инвайтов) как элемент управляемого роста сети, при котором привлечение новых участников рассматривается как вклад в расширение экосистемы и вознаграждается начислением EGP.
• Многоуровневая реферальная программа, интегрированная в экономическую модель сети, поощряющая долгосрочное участие и развитие устойчивых социальных связей внутри экосистемы, всем участникам программы начисляется EGP.
• Система прогрессии ("прокачка") аккаунтов, поощряющая активность с начислением наград за каждый уровень EFI/EGP.

// TODO: paste invites schema code here

Торговля

Внутренний рынок для передачи прав управления аккаунтами и персонажами в рамках правил сети — NFT, игровыми предметами, инвайтами. Возможность создать свой интернет-магазин для торговли любыми, законодательно разрешенными, товарами и услугами.

Социализация или социальная составляющая

Возможность создать свой блог, пользовательские медиа-ресурсы и информационные каналы, используя начисленные на старте монеты EFI/EGP. Возможность продать этот новостной, развлекательный и т.д. ресурс другому участнику сети за EFI.

Интеграции и расширяемость

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

Это превращает закрытую сеть в потенциальный хаб для внешних сервисов.

Текущий статус: Рабочий прототип, в котором частично реализованы описанные функции.

Ключевой демонстрационный продукт: Мини-приложение для Telegram, служащее точкой входа и доказательством работоспособности концепции.

Efimerical Network проектируется как среда, где цифровые взаимодействия не зависят от внешних комиссий, сетевых перегрузок и спекулятивных механизмов публичных блокчейнов. Сеть создаётся как автономная экономико-социальная система с предсказуемыми правилами и эволюцией, формируемой участниками сообщества в рамках установленных протоколов сети.

Дорожная карта: В последующих разделах будет приведено детальное техническое описание с примерами реализации текущего прототипа и планами по миграции на Rust. Текущая реализация использует высокоуровневый стек для ускорения разработки и валидации гипотез, с последующей миграцией критических компонентов на Rust.

// TODO: paste API gateway code here

Принципы и отличия архитектуры

Клиент как суверенная точка входа: архитектура offline-first

Клиент Efi.net — это не просто интерфейс, а самодостаточная ("суверенная") точка входа в экосистему, спроектированная по принципу offline-first. Пользовательский опыт не зависит от постоянной доступности сети: клиент ведёт локальное состояние ключевых сущностей и синхронизирует изменения при появлении соединения.

Локальное состояние как основа автономности

Для хранения состояния используется встроенная база данных SQLite. В ней содержатся:

• пользовательские данные и профиль;
• граф социальных связей и контактов;
• клиентский журнал операций и статусов подтверждения (NFT/транзакции/события);
• кэш медиа-контента (изображения, видео, голосовые сообщения);
• очереди исходящих сообщений и операций, ожидающих подтверждения сети.

Такой подход обеспечивает мгновенный отклик интерфейса, предсказуемую работу при нестабильном соединении и возможность продолжать использование ключевых функций при временной недоступности сети.

// TODO: paste offline queue code here

Многоуровневая защита данных (Defense-in-Depth)

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

• Уровень приложения: разблокировка клиента требует знания секрета (пароль/пин) или биометрической аутентификации (если поддерживается платформой).
• Уровень ОС: ключевой материал защищён средствами безопасного хранилища платформы (Keychain/Keystore), что делает его практическое извлечение крайне затруднительным даже при прямом доступе к файловой системе устройства.

Архитектурный императив: В Efi.net устойчивость и целостность системы обеспечиваются на "краю сети" — в клиенте пользователя. Это фундаментально отличается от модели "тонкого клиента", зависящего от всегда доступного сервера. Такой дизайн является естественным следствием природы закрытой оверлейной сети и её экономики, где ценность создаётся через распределённую активность участников.

Дорожная карта: в последующих релизах предусматривается расширение транспортного уровня для оптимизации медиа-сессий (включая P2P-сценарии), что позволит эффективнее передавать тяжёлый контент при различных типах соединений.

// TODO: paste security model code here

Регистрация без e-mail и номера телефона: снижение рисков захвата

Efi.net не использует регистрацию по электронной почте и телефону и не полагается на внешние каналы "восстановления" аккаунта. В традиционных сервисах процедуры password reset и компрометация e-mail являются одной из наиболее частых точек захвата аккаунтов и социальной инженерии.

Отказ от e-mail/телефона уменьшает поверхность атаки и повышает приватность, поскольку сеть не требует хранения восстановительных контактов и не связывает учетную запись с внешними идентификаторами.

Мнемоническая фраза восстановления: выбор между автоматической генерацией и пользовательским секретом

В Efi.net используется мнемоническая фраза восстановления (Mnemonic Recovery Phrase) как ключевой материал для восстановления доступа к сети. Архитектура системы допускает как автоматическую генерацию криптографически стойкой мнемоники, так и задание пользовательской фразы, обеспечивая баланс между стандартной безопасностью и практической долговечностью.

При регистрации пользователь может выбрать способ создания мнемонической фразы восстановления.

• Вариант автоматической генерации использует стандарт BIP-39 для формирования криптографически стойкой мнемоники. Такая фраза применяется исключительно как источник энтропии для получения внутреннего ключевого материала сети и не предназначена для совместимости с внешними криптовалютными кошельками.
• Альтернативно пользователь может задать собственную мнемоническую фразу восстановления. Клиент отображает индикатор стойкости и предупреждения, а минимальные требования к сложности исключают заведомо слабые варианты. Такой подход ориентирован на практическую долговечность: пользователь может выбрать секрет, который способен воспроизвести через значительное время без зависимости от электронной почты и сторонних сервисов.

Независимо от выбранного способа, внутри системы используется единый mechanism derivation (выведение ключей), обеспечивающий предсказуемость, воспроизводимость и безопасность архитектуры.

В криптосистемах проблема утраты ключевого материала является массовой: различные исследования и оценки указывают на значительный объём цифровых активов, потерянных навсегда вследствие утраты приватных ключей, мнемоник или носителей данных. Выбранный подход направлен на снижение этого класса рисков без компромисса по безопасности.

// TODO: paste mnemonic derivation code here

Дашборд как центр экосистемы: активы, коммуникация и доступ

После регистрации пользователь попадает в дашборд — центральную точку управления аккаунтом и ресурсами внутри Efi.net. Дашборд объединяет ключевые функции сети: управление активами EFI/EGP, коммуникацию и доступ к встроенным сервисам.

Стартовая инициализация: двухуровневая экономика и разная делимость

При создании аккаунта сеть инициализирует два взаимосвязанных экономических инструмента, предназначенных для разных классов операций:

• EFI (Efimerium) — ценная и учётная единица, предназначенная для операций, где важна точная долевая запись.
  • Стартовый баланс: 5.0000 EFI
  • Делимость: до 4 знаков после запятой (минимум 0.0001 EFI).
• EGP (Efimerium Golden Part) — расчётная единица для массовых операций и микроплатежей.
  • Стартовый баланс: 100 000 EGP
  • Тип: целое число, минимальная единица — 1 EGP (неделима).

Фиксированное соотношение единиц:

1 EFI = 10 000 EGP, где 1 EGP = 0.0001 EFI.

Экономический смысл разделения:

EFI играет роль "стратегической" единицы (точность и учёт), а EGP — "операционной" (простые целочисленные расчёты без дробей). Такой дизайн упрощает микротранзакции и снижает ошибки округления на уровне клиента и протокола.

Стартовый набор (5.0000 EFI + 100 000 EGP) позволяет новому пользователю:

• получить доступ к экономике сразу после регистрации;
• совершать сотни микротранзакций в EGP без дробных значений;
• использовать EFI в операциях, где требуется точная долевая запись.

Примечание реализации: протокол транзакций валидирует тип суммы: для EGP — только целые значения, для EFI — значения с точностью до 4 знаков (при превышении точности операция отклоняется). В интерфейсе клиента используются разные элементы ввода: EFI — десятичный формат, EGP — целочисленный.

Конвертация: внутри экосистемы предусмотрен обмен в обе стороны по фиксированному соотношению 1 EFI = 10 000 EGP через внутренний обменный механизм. Реализация обмена (лимиты, частота, правила анти-абьюза) задаётся протоколами сети и описывается в последующих разделах.

Пример:

• Пользователь хочет заплатить 0.5 EFI за услугу → переводит 0.5000 EFI
• Пользователь хочет заплатить 250 EGP за микросервис → переводит 250 EGP (целое число)
• Попытка перевести 0.12345 EFI будет отклонена (5 знаков вместо 4)
• Попытка перевести 100.5 EGP будет отклонена (дробное значение)

// TODO: paste wallet transfer protocol code here

Управление балансами и операциями

Дашборд отображает текущие балансы EFI/EGP и журнал операций, включая начисления, переводы и события сети. Внутренняя экономическая модель исключает комиссии: операции выполняются без транзакционных сборов, а мотивация сети строится на распределении за вклад и активность.

Коммуникация как транспорт действий

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

Ключевая особенность: перевод активов может инициироваться прямо из диалога ("send value in chat") и подтверждается пользователем перед выполнением операции (адресат, gateway_id, сумма, токен).

*gateway_id — уникальный сетевой идентификатор аккаунта/маршрутизации операций внутри Efi.net.

Управляемый доступ и защита от автоматизации

Efi.net использует механизмы управляемого роста и защиты от злоупотреблений. Полный функционал сети открывается по мере прохождения проверки и/или подтверждения приглашения (инвайта). Инвайт рассматривается как инструмент социального доверия и элемент экономики: он может быть ограниченным ресурсом, поощряемым за вклад, и участвовать во внутренних механизмах обмена и распределения.

Встроенные сервисы как модульная экосистема

Дашборд предоставляет доступ к встроенным сервисам и "правам на ресурсы" внутри сети. В частности, пользователь может активировать или приобрести модули для создания собственной витрины/магазина и пользовательского медиа-ресурса (блог/канал) за EGP. Такие модули выступают как инфраструктурные элементы сети и расширяют экономическую активность участников.

Примечание: часть модулей относится к дорожной карте и будет вводиться по мере развития протоколов сети и социальной механики (включая игровые сценарии Infinity Universes).

Идентификация и адресация в сети: gateway_id

В Efi.net каждый аккаунт имеет gateway_id — уникальный сетевой идентификатор, используемый для адресации пользователей и маршрутизации операций внутри закрытой оверлейной сети. В отличие от традиционных систем, идентификация не привязана к электронной почте или номеру телефона: сеть не хранит "восстановительные контакты" и не использует внешние идентификаторы как основу доступа.

Роль gateway_id в экосистеме

• Адрес получателя при переводах EFI/EGP и при операциях обмена.
• Адресация в коммуникации (личные сообщения, групповые форматы по мере развития), включая сценарии "send value in chat", где подтверждение транзакции отображает получателя и его gateway_id.
• Сетевой ключ маршрутизации для внутренних сервисов и модулей (NFT-операции, права на ресурсы, события/статусы подтверждения).

Принципы безопасности и приватности

• gateway_id является публичным идентификатором внутри сети (аналог "адреса"), но не является секретом и не заменяет мнемоническую фразу восстановления/ключевой материал.
• Подтверждение критических операций (переводы, обмен, выдача прав) выполняется через интерфейс с явным отображением адресата (gateway_id) и параметров операции, снижая риск ошибок и социальной инженерии.
• Механизмы управляемого доступа (инвайты/проверка) применяются для защиты сети от автоматизации и злоупотреблений и могут влиять на доступность отдельных операций/модулей.

Примечание по терминологии: gateway_id относится к сетевой адресации и не должен смешиваться с обозначением токена EGP (Efimerium Golden Part). Для протокольного слоя адресации рекомендуется использовать нейтральные термины: "Gateway Layer / Gateway ID".

// TODO: paste gateway routing code here

Встроенный браузер и модульные мини-приложения (Draft)

Efi.net предусматривает встроенный лёгкий браузер/просмотрщик контента как часть клиентского слоя. Его цель — обеспечить единый способ открытия и взаимодействия с ресурсами экосистемы (страницы профилей, блоги/медиа-каналы, витрины магазинов, мини-приложения и dApp-модули), а также безопасную навигацию по внутренним ссылкам и объектам сети.

Роль встроенного браузера

• отображение "ресурсных" страниц экосистемы (медиа-каналы, витрины, профили, NFT-объекты);
• запуск мини-приложений/модулей внутри клиента (в пределах политик безопасности);
• унификация UX: один интерфейс для контента и сервисов, независимо от платформы.

Статус и подход к реализации

Модуль находится в дорожной карте. Возможны два пути реализации:

• форк/встраивание существующего движка WebView (быстрый старт и стабильность),
• собственный лёгкий рендерер/просмотрщик (больше контроля, меньше зависимостей).

Окончательный выбор будет зафиксирован после стабилизации протоколов контента и модели разрешений.

Примечание: в последующих разделах будет описана модель безопасности для встроенного браузера (изоляция, разрешения, политика доступа к ключам и локальным данным).

// TODO: paste browser sandbox code here

Продолжение следует

Следующие разделы будут добавляться по мере фиксации механик в коде и стабилизации протоколов:

• 6. Модель данных и событий (State / Event Model): какие сущности существуют в сети и как фиксируются изменения состояния.
• 7. Протокол транзакций EFI/EGP: типы операций, подтверждения, анти-абьюз, обмен EFI↔EGP.
• 8. Инвайты и управляемый доступ: правила выдачи, лимиты, экономика инвайтов, защита от автоматизации.
• 9. NFT как универсальный контейнер: структура nft.py, права/метаданные, "ресурсные модули" (магазин/медиа) как NFT/сертификаты.
• 10. Модель безопасности: локальное шифрование, управление ключами, принципы минимального доверия, угрозы и допущения.
• 11. Дорожная карта миграции на Rust: какие модули и почему, этапы и критерии готовности.
• 12. Встроенный браузер и модель контента: архитектура, sandbox/изоляция, политики разрешений, интеграция с NFT-ресурсами.

// TODO: paste state/event model code here

Document Status

This document is a "living" technical description of the Efi.net (Efimerical Network) prototype and is updated as the code, protocols, and client modules evolve. Version v0.2 captures the current architectural concept and framework of key mechanisms; subsequent versions will be supplemented with implementation examples, code references, and protocol refinements.

Changelog (brief): v0.2 — clarified offline-first client principles, mnemonic recovery phrase model, two-tier economy EFI/EGP, dashboard structure, and managed access.

Concept and Architecture

Project name: Efi.net

Full network name: Efimerical Network (working prototype)

Type: Closed overlay network, functioning as an isolated digital ecosystem.

The network uses managed membership and admission protocols (invites/verification), enabling controlled growth and reducing automation/spam.

Key innovation: Complete absence of fees for internal transfers, enabled by a two-tier monetary system (EFI/EGP).

Development strategy: Gradual refactoring of critical modules to Rust to ensure maximum performance and security.

Economic Model (Tokenomics)

Base unit: Efimerium EFI (value/accounting unit).

Calculation unit: Efimerium Golden Part EGP (primary currency for transactions). Fixed rate: 1 EFI = 10,000 EGP.

Operation principle: All transactions within the ecosystem are executed with zero fees. Instead of classical consensus models based on competition for computational resources or capital share, Efimerical Network uses a distribution model based on contribution to ecosystem viability.

EGP accrual is provided for maintaining network activity, participation in its development and expansion, including:

• maintaining own nodes;
• generating and validating network states;
• attracting new participants through the invite system;
• developing user points of presence;
• participating in referral and social growth mechanisms.

This model eliminates the need for transaction fees and shifts economic motivation from processing individual operations to sustainable development of the entire ecosystem.

Technically, the network relies on an internal mechanism for accounting states and events, where rewards are tied not to the number of transactions, but to the participant's aggregate contribution to maintaining network activity and infrastructure.

Functional Ecosystem Modules (Built-in Services)

The ecosystem integrates:

NFT Infrastructure

Used not only for digital art, but also as a foundation for creating blogs, storefronts, and mini-applications (dApps), ownership certificates, game items, account characteristics, characters.

// TODO: paste NFT structure code here

Communication

Built-in IUCom messenger for user interaction.

Social Dynamics

• Invite system as an element of managed network growth, where attracting new participants is considered a contribution to ecosystem expansion and is rewarded with EGP accrual.
• Multi-level referral program, integrated into the network's economic model, encouraging long-term participation and development of sustainable social connections within the ecosystem; all program participants receive EGP.
• Account progression ("leveling") system, encouraging activity with rewards for each level in EFI/EGP.

// TODO: paste invites schema code here

Trade

Internal marketplace for transferring account and character management rights within network rules — NFTs, game items, invites. Ability to create your own online store for trading any legally permitted goods and services.

Socialization or Social Component

Ability to create your own blog, user media resources, and information channels using coins EFI/EGP allocated at start. Ability to sell this news, entertainment, etc. resource to another network participant for EFI.

Integrations and Extensibility

The architecture provides for connecting third-party products (e.g., crypto exchanges, payment gateways) through a unified API. The API architecture is designed with the principle of minimal trust and isolation of external integrations from the network core.

This transforms the closed network into a potential hub for external services.

Current status: Working prototype with partially implemented described functions.

Key demonstration product: Mini-application for Telegram, serving as an entry point and proof of concept viability.

Efimerical Network is designed as an environment where digital interactions do not depend on external fees, network congestion, and speculative mechanisms of public blockchains. The network is created as an autonomous economic-social system with predictable rules and evolution, shaped by community participants within established network protocols.

Roadmap: Subsequent sections will provide detailed technical descriptions with implementation examples of the current prototype and plans for migration to Rust. The current implementation uses a high-level stack to accelerate development and hypothesis validation, with subsequent migration of critical components to Rust.

// TODO: paste API gateway code here

Architecture Principles and Differences

Client as Sovereign Entry Point: Offline-First Architecture

The Efi.net client is not just an interface, but a self-sufficient ("sovereign") entry point to the ecosystem, designed on the offline-first principle. User experience does not depend on constant network availability: the client maintains local state of key entities and synchronizes changes when a connection appears.

Local State as Foundation of Autonomy

An embedded SQLite database is used for state storage. It contains:

• user data and profile;
• social graph and contacts;
• client operation log and confirmation statuses (NFT/transactions/events);
• media content cache (images, video, voice messages);
• outgoing message queues and operations awaiting network confirmation.

This approach ensures instant interface response, predictable operation with unstable connections, and the ability to continue using key functions during temporary network unavailability.

// TODO: paste offline queue code here

Multi-Layer Data Protection (Defense-in-Depth)

All local data, including media attachments, is stored encrypted. Access is only possible with the user's key material.

• Application level: client unlock requires knowledge of a secret (password/pin) or biometric authentication (if supported by the platform).
• OS level: key material is protected by the platform's secure storage (Keychain/Keystore), making practical extraction extremely difficult even with direct access to the device file system.

Architectural imperative: In Efi.net, system resilience and integrity are ensured at the "edge of the network" — in the user's client. This fundamentally differs from the "thin client" model, dependent on an always-available server. This design is a natural consequence of the nature of a closed overlay network and its economy, where value is created through distributed participant activity.

Roadmap: subsequent releases will expand the transport layer to optimize media sessions (including P2P scenarios), enabling more efficient transfer of heavy content with various connection types.

// TODO: paste security model code here

Registration Without Email and Phone: Reducing Capture Risks

Efi.net does not use email or phone registration and does not rely on external "recovery" channels. In traditional services, password reset procedures and email compromise are among the most frequent points of account capture and social engineering.

Abandoning email/phone reduces the attack surface and increases privacy, as the network does not require storing recovery contacts and does not link accounts to external identifiers.

Mnemonic Recovery Phrase: Choice Between Automatic Generation and User Secret

Efi.net uses a mnemonic recovery phrase (Mnemonic Recovery Phrase) as key material for network access recovery. The system architecture allows both automatic generation of cryptographically strong mnemonics and user-defined phrases, balancing standard security with practical durability.

During registration, the user can choose the method of creating the mnemonic recovery phrase.

• Automatic generation option uses the BIP-39 standard to form a cryptographically strong mnemonic. Such a phrase is used exclusively as an entropy source for obtaining internal network key material and is not intended for compatibility with external cryptocurrency wallets.
• Alternatively, the user can set their own mnemonic recovery phrase. The client displays a strength indicator and warnings, and minimum complexity requirements exclude obviously weak options. This approach is oriented toward practical durability: the user can choose a secret they can reproduce after a significant time without dependence on email and third-party services.

Regardless of the chosen method, the system uses a unified mechanism derivation (key derivation), ensuring predictability, reproducibility, and architecture security.

In cryptosystems, the problem of key material loss is widespread: various studies and estimates indicate a significant volume of digital assets lost forever due to loss of private keys, mnemonics, or data carriers. The chosen approach aims to reduce this class of risks without compromising security.

// TODO: paste mnemonic derivation code here

Dashboard as Ecosystem Center: Assets, Communication, and Access

After registration, the user enters the dashboard — the central point for managing the account and resources within Efi.net. The dashboard combines key network functions: managing EFI/EGP assets, communication, and access to built-in services.

Initial Initialization: Two-Tier Economy and Different Divisibility

When creating an account, the network initializes two interconnected economic instruments designed for different operation classes:

• EFI (Efimerium) — value and accounting unit for operations where precise fractional recording is important.
  • Starting balance: 5.0000 EFI
  • Divisibility: up to 4 decimal places (minimum 0.0001 EFI).
• EGP (Efimerium Golden Part) — calculation unit for mass operations and micropayments.
  • Starting balance: 100,000 EGP
  • Type: integer, minimum unit — 1 EGP (indivisible).

Fixed unit ratio:

1 EFI = 10,000 EGP, where 1 EGP = 0.0001 EFI.

Economic meaning of separation:

EFI plays the role of a "strategic" unit (precision and accounting), while EGP is "operational" (simple integer calculations without fractions). This design simplifies microtransactions and reduces rounding errors at the client and protocol level.

The starting set (5.0000 EFI + 100,000 EGP) allows a new user to:

• gain access to the economy immediately after registration;
• perform hundreds of microtransactions in EGP without fractional values;
• use EFI in operations requiring precise fractional recording.

Implementation note: the transaction protocol validates amount type: for EGP — only integer values, for EFI — values with precision up to 4 decimal places (operations exceeding precision are rejected). The client interface uses different input elements: EFI — decimal format, EGP — integer.

Conversion: within the ecosystem, exchange in both directions is provided at the fixed ratio 1 EFI = 10,000 EGP through an internal exchange mechanism. Exchange implementation (limits, frequency, anti-abuse rules) is defined by network protocols and described in subsequent sections.

Example:

• User wants to pay 0.5 EFI for a service → transfers 0.5000 EFI
• User wants to pay 250 EGP for a microservice → transfers 250 EGP (integer)
• Attempt to transfer 0.12345 EFI will be rejected (5 decimal places instead of 4)
• Attempt to transfer 100.5 EGP will be rejected (fractional value)

// TODO: paste wallet transfer protocol code here

Balance and Operation Management

The dashboard displays current EFI/EGP balances and operation log, including accruals, transfers, and network events. The internal economic model excludes fees: operations are executed without transaction fees, and network motivation is built on distribution for contribution and activity.

Communication as Action Transport

Communication is the built-in transport layer of the ecosystem. In addition to personal messages, the interface supports extensible interaction formats (groups/clans/raids — as development progresses).

Key feature: asset transfers can be initiated directly from a dialog ("send value in chat") and are confirmed by the user before operation execution (recipient, gateway_id, amount, token).

*gateway_id — unique network identifier for account/operation routing within Efi.net.

Managed Access and Automation Protection

Efi.net uses managed growth mechanisms and abuse protection. Full network functionality opens as verification and/or invite confirmation is passed. An invite is considered a tool of social trust and an economic element: it can be a limited resource, rewarded for contribution, and participate in internal exchange and distribution mechanisms.

Built-in Services as Modular Ecosystem

The dashboard provides access to built-in services and "resource rights" within the network. In particular, users can activate or purchase modules to create their own storefront/store and user media resource (blog/channel) for EGP. Such modules act as network infrastructure elements and expand participant economic activity.

Note: some modules are part of the roadmap and will be introduced as network protocols and social mechanics develop (including Infinity Universes game scenarios).

Network Identification and Addressing: gateway_id

In Efi.net, each account has a gateway_id — a unique network identifier used for user addressing and operation routing within the closed overlay network. Unlike traditional systems, identification is not tied to email or phone number: the network does not store "recovery contacts" and does not use external identifiers as the basis for access.

Role of gateway_id in the Ecosystem

• Recipient address for EFI/EGP transfers and exchange operations.
• Addressing in communication (personal messages, group formats as development progresses), including "send value in chat" scenarios, where transaction confirmation displays the recipient and their gateway_id.
• Network routing key for internal services and modules (NFT operations, resource rights, events/confirmation statuses).

Security and Privacy Principles

• gateway_id is a public identifier within the network (analogous to an "address"), but is not a secret and does not replace the mnemonic recovery phrase/key material.
• Confirmation of critical operations (transfers, exchange, rights issuance) is performed through an interface with explicit display of the recipient (gateway_id) and operation parameters, reducing the risk of errors and social engineering.
• Managed access mechanisms (invites/verification) are applied to protect the network from automation and abuse and can affect the availability of individual operations/modules.

Terminology note: gateway_id refers to network addressing and should not be confused with the EGP token designation (Efimerium Golden Part). For the protocol addressing layer, neutral terms are recommended: "Gateway Layer / Gateway ID".

// TODO: paste gateway routing code here

Built-in Browser and Modular Mini-Applications (Draft)

Efi.net provides for a built-in lightweight browser/content viewer as part of the client layer. Its goal is to provide a unified way to open and interact with ecosystem resources (profile pages, blogs/media channels, storefronts, mini-applications, and dApp modules), as well as secure navigation through internal links and network objects.

Role of Built-in Browser

• display of "resource" pages of the ecosystem (media channels, storefronts, profiles, NFT objects);
• launching mini-applications/modules within the client (within security policies);
• UX unification: one interface for content and services, regardless of platform.

Status and Implementation Approach

The module is on the roadmap. Two implementation paths are possible:

• fork/embedding of an existing WebView engine (quick start and stability),
• custom lightweight renderer/viewer (more control, fewer dependencies).

The final choice will be fixed after content protocol and permission model stabilization.

Note: subsequent sections will describe the security model for the built-in browser (isolation, permissions, access policy to keys and local data).

// TODO: paste browser sandbox code here

To Be Continued

The following sections will be added as mechanics are fixed in code and protocols stabilize:

• 6. Data and Event Model (State / Event Model): what entities exist in the network and how state changes are recorded.
• 7. EFI/EGP Transaction Protocol: operation types, confirmations, anti-abuse, EFI↔EGP exchange.
• 8. Invites and Managed Access: issuance rules, limits, invite economics, automation protection.
• 9. NFT as Universal Container: nft.py structure, rights/metadata, "resource modules" (store/media) as NFTs/certificates.
• 10. Security Model: local encryption, key management, minimal trust principles, threats and assumptions.
• 11. Rust Migration Roadmap: which modules and why, stages and readiness criteria.
• 12. Built-in Browser and Content Model: architecture, sandbox/isolation, permission policies, integration with NFT resources.

// TODO: paste state/event model code here