Pre-launch · status as of 15 October 2026 До запуска · статус на 15 октября 2026

A Layer-1 for transfers, final in one block. Блокчейн для переводов с финальностью в один блок.

Phylox is an independent Layer-1 written from scratch in Go. Tendermint-style BFT consensus produces a block every 4 seconds; once two thirds of the validators sign it, the transfer cannot be reversed. The base fee is 0.0001 YLX, and half of each block's base fees is burned.

Phylox — самостоятельный блокчейн первого уровня, написанный с нуля на Go. BFT-консенсус в духе Tendermint выпускает блок раз в 4 секунды; как только блок подписали две трети валидаторов, перевод уже не откатить. Базовая комиссия — 0,0001 YLX, половина базовых комиссий каждого блока сжигается.

How it worksКак устроено Test resultsРезультаты проверок

Today Phylox runs on a closed test bench of four validators and an observer. There is no public testnet or mainnet yet, and YLX is not sold.

Сейчас Phylox работает на закрытом тестовом стенде: четыре валидатора и наблюдатель. Публичной тестовой и основной сети пока нет, YLX не продаётся.

Height h · round 0Высота h · раунд 0 SchematicСхема
3 / 4quorum, ⌈2n/3⌉кворум, ⌈2n/3⌉
1faulty validator toleratedсбойный валидатор допустим
4 s4 сto the next heightдо следующей высоты
One height of Phylox consensus with four validators, as on the test bench: the proposer offers a block, validators prevote and then precommit; three precommits out of four decide it. Illustration, not live network data. Одна высота консенсуса Phylox с четырьмя валидаторами, как на стенде: сборщик предлагает блок, валидаторы голосуют предварительно, затем окончательно; трёх окончательных голосов из четырёх достаточно для решения. Иллюстрация, а не данные живой сети.
  • 4sс
    Block intervalИнтервал блока
  • 1blockблок
    To finality. No reorgs while <1/3 faultyДо финальности. Без откатов при < 1/3 сбойных
  • 0.00010,0001YLX
    Fee for a basic transferКомиссия простого перевода
  • ~455tx/sпер./с
    Capacity at 256 KiB per blockПропускная способность при блоке 256 КиБ

Protocol parametersПараметры протокола

Every value below is a constant in the node’s params package. A test compares each constant, by name and value, with the parameter table of the specification, so the code and the documents cannot drift apart.

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

Phylox protocol parametersПараметры протокола Phylox
ParameterПараметр ValueЗначение In codeВ коде
Block intervalИнтервал блока 4 seconds4 секунды BlockInterval = 4 * time.Second
FinalityФинальность Single block. A block signed by ⌈2n/3⌉ validators is never rolled back while fewer than a third of validators are faultyОдин блок. Блок с подписями ⌈2n/3⌉ валидаторов не откатывается, пока сбойных валидаторов меньше трети ConsensusThresholdNum/Den = 2/3
Block sizeЛимит блока 256 KiB256 КиБ Up to 1,820 minimal 144-byte transfers per block, about 455 per second До 1 820 минимальных переводов по 144 байта в блоке, около 455 в секунду MaxBlockSize = 256 * 1024
Validator setСостав валидаторов Equal votes, up to 100 validatorsРавные голоса, до 100 валидаторов Tolerates ⌊(n−1)/3⌋ faulty validators Выдерживает ⌊(n−1)/3⌋ недобросовестных MaxValidators = 100
Initial supplyНачальное предложение 100,000,000 YLX at genesis100 000 000 YLX в генезисе InitialSupply = 100_000_000
IssuanceЭмиссия 5% of the initial supply in year 1, then 4%, 3%, 2%; 1% a year from year 5 on5% от начального предложения в первый год, затем 4%, 3%, 2%; с пятого года — 1% в год A year is 7,884,000 blocks; nodes count height, not calendar time Год — 7 884 000 блоков; узлы считают высоту, а не календарь InflationFirstYearBP = 500 InflationFloorBP = 100
Block rewardНаграда за блок 10% to the proposer, 90% split among validators whose signatures are in the parent commit10% сборщику, 90% — поровну валидаторам, чьи подписи есть в коммите родителя Shares of absent validators are not minted Доли отсутствующих не печатаются ProposerShareBP = 1_000 VoterShareBP = 9_000
Fee burnСжигание 50% of block fees are burned; the other half goes to the proposer50% комиссий блока сжигается, вторая половина — сборщику BurnShareBP = 5_000
Base feeБазовая комиссия 0.0001 YLX for a minimal transfer (695 nano per unit of weight)0,0001 YLX за минимальный перевод (695 нано за единицу веса) Automatic adjustment, ±12.5% per block around a 50% fill target, is specified but not yet active Автоподстройка на ±12,5% за блок вокруг загрузки 50% описана в спецификации, но ещё не включена MinFeeNano = 100_000 BaseFeePerWeightNano = 695
New-account surchargeДоплата за новый адрес 0.001 YLX on the first transfer to an address; burned in full0,001 YLX за первый перевод на адрес; сжигается целиком AccountCreationFeeNano
PrecisionТочность 9 decimals: 1 YLX = 10⁹ nano. Integer arithmetic only9 знаков: 1 YLX = 10⁹ нано. Только целочисленная арифметика Decimals = 9
Chain ID 897688 (test network: 897689), signed into every transaction897688 (тестовая сеть — 897689), входит в подпись каждой транзакции ChainID = 897688
CryptographyКриптография ECDSA secp256k1 with low-s signatures; Keccak-256 with a separate domain for every hash; Ethereum-format addressesECDSA secp256k1, только low-s; Keccak-256 с отдельным доменом для каждого хеша; адреса в формате Ethereum Domain* = "phylox/…/v1"

Capacity is computed from the measured size of a minimal signed transfer; it is a protocol ceiling, not a benchmark of a public network.Пропускная способность вычислена из измеренного размера минимального подписанного перевода; это потолок протокола, а не замер публичной сети.

How it worksКак устроено

Phylox does one thing — moves value between accounts — and keeps every part of that path small enough to reason about. Each decision has a written record with its trade-offs and known weak points.

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

BFT consensus, built from scratchBFT-консенсус, написанный с нуля

A Tendermint-style protocol implemented in Go rather than taken from CometBFT. A proposer chosen in turn offers a block; validators prevote, then precommit, and ⌈2n/3⌉ precommits decide it.

Протокол в духе Tendermint, реализованный на Go, а не взятый из CometBFT. Сборщик по очереди предлагает блок; валидаторы голосуют предварительно, затем окончательно, и ⌈2n/3⌉ окончательных голосов решают его судьбу.

  • Locking and proof-of-lock rules keep safety across rounds
  • Timeouts: proposal 3 s + 0.5 s per round, votes 1 s + 0.5 s
  • On-disk guard refuses to sign twice at the same height and round
  • Блокировка и доказательство блокировки сохраняют безопасность между раундами
  • Сроки: предложение 3 с + 0,5 с на раунд, голоса 1 с + 0,5 с
  • Защита на диске не даёт подписать дважды на одной высоте и раунде

SPEC §6 · ADR-0031

Final in one blockОкончательно за один блок

Any two quorums of two thirds share at least one honest validator, so two different blocks at the same height cannot both be decided. There are no forks to wait out: a transfer is final when its block is.

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

  • Every block carries the commit of its parent
  • No block is executed before its commit is verified, including blocks received during sync
  • The chain keeps going with three of four validators online
  • Каждый блок несёт коммит своего родителя
  • Ни один блок не исполняется до проверки коммита — и при синхронизации тоже
  • Сеть продолжает работу при трёх валидаторах из четырёх

SPEC §5–6 · ADR-0031

State with Merkle proofsСостояние с доказательствами Меркла

Accounts hold balances and nonces. State is stored flat in Pebble for one-read lookups and committed to a binary sparse Merkle tree whose root is in every block header.

Аккаунты хранят баланс и счётчик. Состояние лежит в Pebble плоско — одно чтение на запрос — и фиксируется двоичным разреженным деревом Меркла, корень которого есть в каждом заголовке.

  • Proofs of inclusion and of absence
  • Transactions committed by a Merkle root, with their count under the header hash
  • A block applies atomically, or not at all
  • Доказательства наличия и отсутствия
  • Транзакции заверены корнем Меркла, их число — под хешем заголовка
  • Блок применяется целиком или не применяется вовсе

SPEC §5, §8 · ADR-0020

Issuance and fee burnЭмиссия и сжигание

Every node computes the block reward from the block height with integer arithmetic, rounding down. A validator cannot write its own reward into a block.

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

  • 10% to the proposer, 90% to the signers of the parent commit
  • Half of each block's base fees is burned, so net issuance shrinks as usage grows
  • The new-account surcharge is burned in full
  • 10% сборщику, 90% подписавшим коммит родителя
  • Половина базовых комиссий каждого блока сгорает: чем больше переводов, тем меньше чистый прирост предложения
  • Доплата за новый адрес сгорает целиком

SPEC §7 · ADR-0007

Validator set in chain stateСостав валидаторов в состоянии сети

Membership is part of the state, not a configuration file. Each validator has an owner: a separate cold address that receives rewards and votes on who joins or leaves.

Состав — часть состояния сети, а не файл настроек. У каждого валидатора есть владелец: отдельный холодный адрес, который получает награды и голосует, кого включить или исключить.

  • Add, remove or change owner by a two-thirds vote of owners
  • The node key holds no funds
  • Evidence of a double vote removes a validator at the next height
  • Включение, исключение и смена владельца — голосованием двух третей владельцев
  • Ключ узла денег не держит
  • Доказательство двойного голоса исключает валидатора со следующей высоты

SPEC §6 · ADR-0031

Network and keysСеть и ключи

Peers connect over TCP with a Noise XX handshake bound to the chain ID and genesis. A node listens only on 127.0.0.1 until its operator opens it, so the operator’s IP is not announced by default.

Узлы соединяются по TCP через рукопожатие Noise XX, привязанное к номеру сети и генезису. Пока оператор сам не откроет узел, тот слушает только 127.0.0.1, и IP оператора в сеть не уходит.

  • Peer scoring and bans by key and IP
  • Wallet keystore: Argon2id + XChaCha20-Poly1305; the key never leaves the wallet
  • Node RPC on loopback only, with a fresh token on every start
  • Штрафные очки и баны по ключу и IP
  • Хранилище ключа: Argon2id + XChaCha20-Poly1305; ключ не покидает кошелёк
  • RPC узла — только на loopback, с новым токеном при каждом запуске

SPEC §9–11 · ADR-0026, ADR-0027

Life of a transferПуть перевода

  1. WalletКошелёк

    SignПодпись

    The wallet signs locally: a native transfer, or a legacy Ethereum (EIP-155) transfer from MetaMask.

    Кошелёк подписывает у себя: родной перевод или перевод Ethereum (legacy, EIP-155) из MetaMask.

  2. MempoolОчередь

    AdmitПриём

    Form, validity window, fee, signature, nonce and balance are checked before the transaction takes any space.

    Форма, окно жизни, комиссия, подпись, счётчик и баланс проверяются до того, как транзакция займёт место.

  3. ProposerСборщик

    ProposeПредложение

    Up to 256 KiB of transactions, each dry-run against the state, so the offered block is valid.

    До 256 КиБ транзакций, каждая прогнана по состоянию заранее, поэтому предложенный блок годен.

  4. ValidatorsВалидаторы

    DecideРешение

    Prevote, then precommit. ⌈2n/3⌉ precommits decide the block, and it is final.

    Предварительный голос, затем окончательный. ⌈2n/3⌉ окончательных голосов решают блок — он окончателен.

  5. Every nodeКаждый узел

    CommitЗапись

    State changes are written atomically with the new state root; the commit signatures travel in the next block.

    Изменения состояния записываются одной пачкой с новым корнем; подписи коммита уходят в следующий блок.

In practice a transfer lands in a block within 4–8 seconds and is final immediately.На практике перевод попадает в блок за 4–8 секунд и сразу становится окончательным.

What has been verifiedЧто проверено

Figures on this page come from the project’s verification log: each claim names the test or the recorded run behind it. Failed runs are listed alongside the passed ones.

Цифры на этой странице взяты из журнала проверок проекта: у каждого утверждения названа проверка или записанный прогон. Неудачные прогоны перечислены рядом с удачными.

PassedПройден 24-hour soak test · 13–14 October 2026 · Go 1.27.2Суточный прогон · 13–14 октября 2026 · Go 1.27.2

Four validators and an observer ran for a full day under load, with a validator killed every hour. The monitor recorded no failures.Четыре валидатора и наблюдатель проработали сутки под нагрузкой, раз в час один валидатор принудительно останавливался. Монитор не записал ни одного сбоя.

24 h 00 m24 ч 00 минcontinuous run, no interventionнепрерывно, без вмешательства
21,34921 349blocks, same height on all 5 nodesблоков, одна высота у всех 5 узлов
0failures by the monitor’s rulesсбоев по правилам монитора
23forced validator kills, one an hourпринудительные остановки валидаторов, раз в час
24one-minute bursts of 700 tx/s, ~1.5× block capacityминутных всплеска по 700 пер./с — в 1,5 раза больше вместимости блоков
128 MiB128 МиБpeak heap per validator; no leaksнаибольшая куча валидатора; утечек нет

Failure rules, fixed in numbers before the runПравила сбоя, записанные числами до прогона

  • No new block for longer than 30 seconds
  • A fork, or diverging state between nodes
  • Any peer ban
  • A restarted node not caught up within 3 minutes
  • Any mempool not drained 3 minutes after a burst
  • Heap or goroutines growing steadily to 3× the first-hour peak, or above 2 GiB / 10,000
  • Новых блоков нет дольше 30 секунд
  • Развилка или расхождение состояния между узлами
  • Любой бан пира
  • Перезапущенный узел не догнал сеть за 3 минуты
  • Очередь любого узла не опустела за 3 минуты после всплеска
  • Куча или горутины монотонно растут до тройного пика первого часа или выше 2 ГиБ / 10 000

VERIFICATION · ADR-0029, ADR-0034

Every 24-hour run so farВсе суточные прогоны

Dates (2026)Даты (2026) ResultИтог What happenedЧто было
4–5 Oct4–5 окт.PassedПройден First run on BFT. Height 21,313; after a further 17 hours, block hashes matched on all five nodes at every one of 36,743 heights.Первый прогон на BFT. Высота 21 313; ещё через 17 часов хеши блоков совпали у всех пяти узлов на всех 36 743 высотах.
6 Oct6 окт.FailedНе пройден A peer was banned for message rate in the first load burst. Fixed (ADR-0037) and rerun the same day.В первом же всплеске нагрузки пир получил бан за скорость сообщений. Исправлено (ADR-0037), прогон повторён в тот же день.
6–7 Oct6–7 окт.PassedПройден With the block explorer indexing alongside. Height 21,307, no bans, no leaks.Вместе с работающим обозревателем. Высота 21 307, банов и утечек нет.
7–8 Oct7–8 окт.FailedНе пройден Five stalls of 34–52 seconds within 12 minutes. Traced to the host PC freezing — all nodes and the load generator went silent at once — not to the protocol.Пять остановок по 34–52 секунды за 12 минут. Причина — зависания самого ПК (все узлы и нагрузчик замолкали разом), а не протокол.
8–9 Oct8–9 окт.PassedПройден Rerun on a quiet host. Height 21,336. Built with Go 1.27.0.Повтор на ненагруженном ПК. Высота 21 336. Сборка на Go 1.27.0.
10–13 Oct10–13 окт.Not passedНе засчитаны Attempts after moving to Go 1.27.2 failed or were cut short. Causes found: host pauses of up to 190 seconds (the monitor now measures and subtracts them) and a metrics bug that briefly showed a restarted validator as outside the set (fixed in the code with a test, but after the passed run was built: that run used a build without this fix). Two attempts were stopped externally with no protocol failures.Попытки после перехода на Go 1.27.2 падали или прерывались. Найденные причины: паузы ПК до 190 секунд (монитор теперь их измеряет и вычитает) и ошибка метрик, из-за которой перезапущенный валидатор на мгновение выглядел вне состава (исправлено в коде с тестом, но уже после сборки зачтённого прогона: он шёл на сборке без этого исправления). Две попытки остановлены извне, сбоев протокола в них не было.
13–14 Oct13–14 окт.PassedПройден Go 1.27.2. Height 21,349, zero host pauses. The full check suite and the release build passed afterwards.Go 1.27.2. Высота 21 349, пауз хоста 0. После прогона полная проверка и сборка релиза прошли.

Engineering checksИнженерные проверки

12 / 12

Steps in the full checkШагов полной проверки

Formatting, build, vet, tests, race detector, project rules, 32-bit build and tests, throughput, scripts, linter, dependency vulnerability scan.

Форматирование, сборка, vet, тесты, детектор гонок, правила проекта, сборка и тесты под 32 бита, пропускная способность, скрипты, линтер, уязвимости зависимостей.

94.9 M94,9 млн

Fuzzing inputsВходов фаззинга

Across the decoder and signature parsing, with no panics or round-trip mismatches. Fuzzing finds bugs; it does not prove their absence.

Разбор байт, круговые проходы кодека и разбор подписей — ни одной паники и ни одного расхождения. Фаззинг находит ошибки, но не доказывает их отсутствие.

64 / 64

Mutations caughtМутаций поймано

Bugs deliberately put back into the code to confirm that the test named for each claim actually fails.

Ошибки, намеренно возвращённые в код, чтобы убедиться: тест, названный для утверждения, действительно падает.

14

Review findings, all fixedНаходок проверки, все закрыты

An internal adversarial review of the core, cryptography, encoding and state found 5 high- and 9 medium-severity issues. Each is now pinned by a regression test.

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

16×

Signature-check headroomЗапас по проверке подписей

A full block of signatures verifies in 248 ms against a 4-second interval. The check suite fails if headroom drops below 2×.

Полный блок подписей проверяется за 248 мс при интервале 4 секунды. Проверка падает, если запас опустится ниже двукратного.

35 / 35

Ethereum tooling checksПроверок с инструментами Ethereum

eth-account (Python): 35 of 35 checks against a live node after review; ethers v6 checked by a separate script. MetaMask 13.50.0 added the network and sent two transfers that were included in blocks.

eth-account (Python): 35 проверок из 35 против живого узла после ревью; ethers v6 проверен отдельным сценарием. MetaMask 13.50.0 добавил сеть и отправил два перевода, оба вошли в блоки.

Not verified yetЕщё не проверено

  • Independent external audit. Not done. The network is not meant to carry real value before one.
  • Независимый внешний аудит. Не проводился. До него сеть не должна нести реальную стоимость.
  • Many machines over the internet. Every run so far has been on one machine, with real network latency and loss untested.
  • Много машин через интернет. Все прогоны пока на одной машине; реальные задержки и потери сети не проверены.
  • A 24-hour run in containers. The Docker bench is ready; the full-day run in it has not been done.
  • Суточный прогон в контейнерах. Стенд в Docker готов, суточного прогона в нём ещё не было.
  • Reproducible builds, confirmed by others. Local rebuilds give identical checksums; outside confirmation is part of the launch plan.
  • Воспроизводимые сборки, подтверждённые другими. Повторная сборка у автора даёт те же контрольные суммы; подтверждение посторонними — часть плана запуска.

RoadmapПлан

Status as of 15 October 2026. A phase starts only when the previous one meets its criterion; dates are the current plan, and if a criterion is not met, genesis moves.

Статус на 15 октября 2026. Фаза начинается, только когда предыдущая выполнила свой критерий; даты — текущий план, и если критерий не выполнен, генезис сдвигается.

  1. A

    Closed test networkЗакрытая тестовая сеть

    FinishingЗавершается

    Criterion: a 24-hour run with no monitor failures — met by four runs, the latest on 14 October. Outstanding: the same run in containers.

    Критерий: суточный прогон без сбоев монитора — выполнен четырьмя прогонами, последний 14 октября. Осталось: такой же прогон в контейнерах.

  2. B

    Public testnet with a faucetПубличная тестовая сеть с краном

    Planned · Dec 2026План · декабрь 2026

    Own servers, faucet, explorer, operator docs and the source code opened. Criterion: 30 days without a halt, an outsider runs a node from the docs and syncs, at least two external validators.

    Свои серверы, кран, обозреватель, документация операторов и открытый код. Критерий: 30 суток без остановки, посторонний поднимает узел по документации и догоняет сеть, не меньше двух внешних валидаторов.

  3. C

    External audit and bug bountyВнешний аудит и баг-баунти

    PlannedПлан

    Audit of networking, consensus, RPC, key storage, vesting and genesis; a bounty running on the testnet for at least four weeks. Criterion: all critical and high findings fixed and the report published.

    Аудит сети, консенсуса, RPC, хранилища ключей, блокировки и генезиса; программа вознаграждений на тестовой сети не меньше четырёх недель. Критерий: все критические и высокие находки закрыты, отчёт опубликован.

  4. D

    Mainnet genesisГенезис основной сети

    Target · Mar 2027Цель · март 2027

    Genesis file published 14 days ahead, signed reproducible builds. Criterion: several independent people build the same binary hash and check the genesis.

    Файл генезиса публикуется за 14 дней, сборки подписаны и воспроизводимы. Критерий: несколько независимых людей собрали бинарник с тем же хешем и проверили генезис.

  5. E

    First external validatorsПервые внешние валидаторы

    After genesisПосле генезиса

    Added by on-chain vote, followed by a public explorer and a simple wallet for people new to the network.

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

Build stagesЭтапы разработки

  1. 01Core: types, hashing, Merkle treeЯдро: типы, хеши, дерево Меркла✓
  2. 02Keys and walletКлючи и кошелёк✓
  3. 03Transactions and encodingТранзакции и кодек✓
  4. 04State and Merkle proofsСостояние и доказательства✓
  5. 05Genesis and chain storageГенезис и хранение цепочки✓
  6. 06Proof-of-authority consensusКонсенсус PoA→ BFT→ BFT
  7. 07Mempool and block buildingМемпул и сборка блоков✓
  8. 08Peer-to-peer networkСеть узлов✓
  9. 09RPC and command-line walletRPC и кошелёк в командной строке✓
  10. 10Local test network, load and monitorТестовый стенд, нагрузка, монитор✓
  11. 11BFT consensusКонсенсус BFT✓
  12. 12Block explorerОбозреватель✓
  13. 13Ethereum wallet compatibilityСовместимость с кошельками Ethereum✓
  14. 14Public launchПубличный запускin progressв работе

Stage 14 so far: genesis vesting enforced by the protocol, node operator guide, reproducible build script, CI. Next: servers, opening the source, code signing.

Сделано в этапе 14: блокировка долей генезиса правилом протокола, руководство оператора узла, скрипт воспроизводимой сборки, CI. Дальше: серверы, открытие кода, подпись программ.

Decentralization milestonesВехи децентрализации

At genesis every validator will be run by the founder. That is stated up front, together with measurable steps to remove it — each one checkable by anyone from the validator list.

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

M0

GenesisГенезис

All validators with the founder, announced together with the dates of the next milestones.

Все валидаторы у основателя; объявлено вместе с датами следующих вех.

Day 0День 0

M1

No single party finalizes blocksНикто не финализирует блоки в одиночку

The founder holds less than a quorum, e.g. 4 of 7 with a quorum of 5.

У основателя меньше кворума, например 4 из 7 при кворуме 5.

Within 3 monthsДо 3 месяцев

M2

No single party halts the chainНикто в одиночку не остановит сеть

The founder runs at most ⌊(n−1)/3⌋ validators, e.g. 3 of 10, and cannot change membership alone.

У основателя не больше ⌊(n−1)/3⌋ валидаторов, например 3 из 10, и состав он один не меняет.

Within 9 monthsДо 9 месяцев

M3

No dominant operatorНет доминирующего оператора

No operator above one third; at least 7 independent operators, 3 hosting providers and 2 countries.

Ни у кого больше трети; не меньше 7 независимых операторов, 3 хостеров и 2 стран.

Within 18 monthsДо 18 месяцев

After launch, in order of priorityПосле запуска, по важности

  1. Stealth addresses — the first privacy layer. Today all transfers are transparent
  2. Mobile wallet with passkeys and social recovery
  3. Short names instead of 42-character addresses
  4. Snapshot sync for new nodes
  5. Confidential amounts with zero-knowledge proofs
  6. Automatic fee adjustment
  1. Скрытые адреса — первый слой приватности. Сейчас все переводы прозрачны
  2. Мобильный кошелёк с passkey и социальным восстановлением
  3. Короткие имена вместо адреса из 42 символов
  4. Синхронизация по снимку состояния для новых узлов
  5. Скрытые суммы на доказательствах с нулевым разглашением
  6. Автоподстройка комиссии

Deliberately not before launchСознательно не до запуска

  • Smart contracts and a virtual machine
  • Bridges to other chains
  • Tokens on top of the network
  • Staking and slashing — not until the coin has a market price
  • Смарт-контракты и виртуальная машина
  • Мосты в другие сети
  • Токены поверх сети
  • Стейкинг и слэшинг — не раньше, чем у монеты появится рыночная цена

For developersРазработчикам

The source code is not public yet; it opens with the public testnet. This is what the interfaces look like today. There is no public RPC endpoint: the addresses below belong to a node you run yourself.

Исходный код пока закрыт и откроется вместе с публичной тестовой сетью. Ниже — как выглядят интерфейсы сегодня. Публичного RPC нет: адреса ниже относятся к узлу, который вы запускаете сами.

Node and walletУзел и кошелёк

phyloxd runs a validator (with a key) or an observer. phylox-cli manages encrypted keystores, sends transfers, looks up transactions and votes on the validator set. Release builds for Linux (amd64, arm64) and Windows (amd64).

phyloxd работает валидатором (с ключом) или наблюдателем. phylox-cli ведёт зашифрованные хранилища ключей, отправляет переводы, показывает транзакции и голосует за состав валидаторов. Сборки для Linux (amd64, arm64) и Windows (amd64).

JSON-RPC

JSON-RPC 2.0 over HTTP, loopback only, with a bearer token the node writes to rpc.cookie on every start. Methods include phylox_status, phylox_getAccount, phylox_sendRawTransaction, phylox_getBlockByHeight, phylox_getValidators and phylox_consensus.

JSON-RPC 2.0 поверх HTTP, только loopback, с токеном, который узел пишет в rpc.cookie при каждом запуске. Среди методов — phylox_status, phylox_getAccount, phylox_sendRawTransaction, phylox_getBlockByHeight, phylox_getValidators и phylox_consensus.

MetaMask and Ethereum librariesMetaMask и библиотеки Ethereum

An optional eth_* endpoint lets MetaMask, ethers and similar tools send YLX. The wallet signs an ordinary legacy (EIP-155) transfer; no Snap or plugin is needed. The endpoint is read-only apart from submitting signed transfers.

Необязательный эндпоинт eth_* позволяет MetaMask, ethers и похожим инструментам переводить YLX. Кошелёк подписывает обычный перевод legacy (EIP-155); Snap и дополнения не нужны. Кроме отправки подписанных переводов, эндпоинт только читает.

ExplorerОбозреватель

A separate read-only program indexes blocks, transactions and address history from a node over RPC and serves plain HTML pages, with no JavaScript and no external resources.

Отдельная программа только для чтения: строит индекс блоков, транзакций и истории адресов по RPC узла и отдаёт простые HTML-страницы — без JavaScript и внешних ресурсов.

Network identifiers and default portsИдентификаторы сети и порты по умолчанию
Main networkОсновнаяTest networkТестовая
Chain ID897688 0xdb298897689 0xdb299
SymbolСимволYLXYLX
Decimals in walletsЗнаков в кошельках1818
P2P2976829769
RPC 127.0.0.12876828769
eth_* 127.0.0.12576825769
Node status over JSON-RPCСтатус узла по JSON-RPCbash
curl -s http://127.0.0.1:28769/ \
  -H "Authorization: Bearer $(cat data/rpc.cookie)" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"phylox_status","params":[]}'
Add a local test node to MetaMaskДобавить локальный тестовый узел в MetaMaskjs
await ethereum.request({
  method: "wallet_addEthereumChain",
  params: [{
    chainId: "0xdb299",
    chainName: "Phylox Testnet",
    nativeCurrency: { name: "Phylox", symbol: "YLX", decimals: 18 },
    rpcUrls: ["http://127.0.0.1:25769"]
  }]
});

Phylox is not an EVM. There are no smart contracts or tokens: a transfer with non-empty data is rejected and eth_call returns 0x. Native YLX has 9 decimals; wallets see 18, so amounts must be whole multiples of 10⁹ wei.

Phylox — не EVM. Смарт-контрактов и токенов нет: перевод с непустым data отвергается, eth_call возвращает 0x. У YLX 9 знаков после точки, кошелёк видит 18, поэтому сумма должна быть кратна 10⁹ wei.