Flare – EVM-compatible Layer 1, в которой validators одновременно поддерживают consensus и встроенные data protocols. FTSOv2 публикует price и time-series feeds, Flare Data Connector подтверждает события внешних chains, а FAssets использует эти данные для выпуска overcollateralized representations активов без smart contracts.
К августу 2026 года FXRP уже работает на Flare mainnet, а более новые версии и следующие FAssets внедряются поэтапно. FlareDrops завершились 30 января 2026 года. Утверждённая FIP.16 снижает target inflation и перестраивает rewards, но часть изменений требует phased rollout и hard fork.
История
Flare основали Hugo Philion, Sean Rowan и Nairi Usher. Проект вырос из идеи добавить trust-minimized smart-contract utility активам вроде XRP. Ранняя концепция Spark token, XRP snapshot и F-Assets несколько раз менялась до production launch.
Songbird canary network запустилась в сентябре 2021 года. Она стала live-средой с реальной стоимостью для проверки upgrades перед Flare. Genesis Flare состоялся 14 июля 2022 года, а public Token Distribution Event – 9 января 2023 года.
FTSOv1 обеспечивал первые price feeds. В 2024 году FTSOv2 добавил block-latency updates и масштабируемые feeds, а FDC оформился как enshrined attestation protocol. FXRP тестировался на Songbird с декабря 2024 года и вышел на Flare mainnet в сентябре 2025 года.
В январе 2026 года завершились 36 monthly FlareDrops. Governance 24 апреля одобрило FIP.16: target inflation снижается с 5% до 3%, hard cap – с 5 млрд до 3 млрд FLR, а network revenue должен направляться через FIRE на burn и ecosystem.
Команда
Сооснователи Flare – Hugo Philion, Sean Rowan и Nairi Usher. Flare Foundation координирует protocol development, grants и governance proposals. Flare Labs создаёт FAssets и interoperability products. Это связанные, но разные роли.
Validators и data providers работают независимо от Foundation, хотя entry, rewards и software сильно зависят от protocol rules. Foundation исторически участвовала в bootstrap и может предлагать крупные upgrades. Governance vote требуется для FIP, но concentration delegated FLR влияет на результат.
Базовая сеть
Flare совместима с EVM и использует Avalanche-derived consensus architecture с C-Chain для smart contracts и P-Chain для staking. EVM developer получает Solidity, familiar addresses и JSON-RPC, а FLR оплачивает gas.
Validator подписывает blocks и блокирует stake на P-Chain. Для участия как полноценная Flare Entity он также запускает Flare Systems Protocol infrastructure: FTSO и FDC clients, indexer и system client. Таким образом security budget поддерживает не только ordering transactions, но и data production.
Архитектурное родство с Avalanche не делает сети идентичными. Flare имеет собственные chains, validator requirements, inflation и enshrined protocols.
FTSOv2
Flare Time Series Oracle выдаёт price и другие time-series feeds. Block-latency feeds обновляются примерно с каждым Flare block. Для каждого update VRF выбирает stake-weighted sample providers, которые публикуют deltas.
Scaling feeds используют более полный commit-reveal process и anchors, обновляемые медленнее. Fast updates сверяются с anchors, чтобы сочетать скорость и устойчивость. Во время volatility protocol может увеличить sample.
Около ста providers поддерживают feeds, но реальная децентрализация зависит от ownership, delegated weight и data sources. Если многие providers читают одну exchange API, формальное число operators переоценивает независимость.
FTSO встроен в network economics, однако smart contract всё равно должен выбрать feed, decimals, staleness limits и failure behavior. Общая природа oracle attacks рассмотрена в обзоре Chainlink.
Flare Data Connector
FDC подтверждает внешние факты: payment в Bitcoin, Dogecoin или XRP Ledger, EVM transaction, block height и другие типизированные attestations. User публикует request, providers проверяют source chain и голосуют за validity.
После достижения более 50% signature weight responses собираются в Merkle tree, а root публикуется в Relay contract. Приложение получает response и Merkle proof из DA layer и проверяет его on-chain.
FDC не является general-purpose «оракулом всего интернета». Поддерживаются конкретные attestation types, source networks и verification rules. Неверный запрос, reorg внешней chain или correlated provider bug может задержать или сорвать подтверждение.
Для XRP Ledger FDC особенно важен: он доказывает payment без изменения XRPL consensus. Это дополняет функции сети, описанные в обзоре XRP Ledger, но не переносит сам ledger внутрь Flare.
FAssets и FXRP
FAssets выпускают ERC-20 representation актива, который не имеет native smart contracts. Первым production-активом стал FXRP – представление XRP один к одному по unit, обеспеченное underlying XRP и overcollateralization agents.
Minter резервирует collateral у выбранного agent и отправляет XRP на его address. FDC подтверждает payment, после чего Asset Manager выпускает FXRP. При redemption FXRP сжигается, а agent переводит XRP обратно в XRPL.
Это не классический multisig bridge, но и не trustless teleport. Agent временно контролирует underlying address и обязан выполнить redemption. Если он не платит, contracts компенсируют redeemer из vault и pool collateral по protocol rules.
Vault collateral предоставляется agent, pool collateral – agent и FLR holders. Ratios, liquidation thresholds и minting capacity ограничивают выпуск. Overcollateralization защищает от части defaults, но price gaps, oracle failure и smart contract bug могут превысить buffer.
Core Vault и версии FAssets
Core Vault хранит часть underlying assets и повышает capital efficiency, позволяя agents освобождать collateral. Это отдельный компонент с operational и access controls. Direct redemption из Core Vault может иметь whitelisting requirements и не равна обычному permissionless redemption через agents.
FXRP v1.2 был действующей mainnet-версией после запуска 2025 года. В 2026 году v1.3 тестировался на Songbird и готовился к mainnet, добавляя direct minting через XRPL destination tags и новые safety controls. До фактической активации эти возможности нельзя обещать всем пользователям.
FBTC и FDOGE проходили canary testing, но наличие документации не означает одновременно unlimited production minting на Flare. Current product page прямо называет FXRP первым live FAsset, а BTC – следующим направлением.
Validators, staking и delegation
FLR можно stake на P-Chain validator. Stake блокируется на выбранный период и участвует в network security. Минимумы, maximum share и lock duration задаются текущими parameters, поэтому интерфейсные цифры нельзя фиксировать без on-chain проверки.
Отдельно WFLR holder делегирует FTSO voting power data provider, не переводя token ему. FTSO delegation не равна P-Chain staking: различаются lockup, risks и reward source. Один provider часто совмещает обе роли в Flare Entity.
После FIP.16 больший относительный вес rewards должен перейти staking, а provider получает minimum долю relevant revenue. Rollout phased: часть parameter changes применяется через reward cycles, часть требует hard fork. Поэтому dashboard важнее старой схемы 70/30.
FLR и WFLR
FLR используется для gas, staking, governance и ecosystem collateral. WFLR – ERC-20 wrapper один к одному, позволяющий delegation и smart-contract use. Wrap не создаёт новый economic supply, а unwrap возвращает native FLR.
Genesis supply составлял 100 млрд FLR. FIP.01 изменила public distribution: 15% соответствующей allocation выдали на TDE, остальные 85% распределялись monthly eligible WFLR holders. Последний FlareDrop завершился 30 января 2026 года.
Старые инструкции «wrap для ежемесячного FlareDrop» больше не дают эту reward component. Protocol rewards за FTSO delegation, staking и FAssets participation продолжаются по отдельным правилам.
Инфляция, burn и FIP.16
FIP.01 задавала schedule 10% в первый год, 7% во второй и 5% далее с annual cap 5 млрд FLR. Transaction fees сжигаются, а unclaimed rewards и некоторые failed requests также могут сокращать supply.
Одобренная FIP.16 устанавливает target 3% и cap 3 млрд, исключает burn address и некоторые недоступные pools из inflatable base. Это target после governance execution, а не обещание точной net inflation в каждый день перехода.
FIRE – Flare Income Reinvestment mechanism – должен собирать network revenue в FLR, FAssets, stablecoins и других assets. Primary mandate – offset inflation и burn, secondary – ecosystem и Foundation. Часть дизайна, включая MEV capture через builder architecture, требует последующих технических deployments.
Рост base gas fee увеличивает burn, но его фактический эффект зависит от transactions и price FLR. Deflation не гарантирована: если issuance выше burns и FIRE purchases, supply продолжит расти.
Управление
WFLR даёт voting power для Flare Improvement Proposals. Token delegation к FTSO и governance delegation могут использовать разные choices. Некоторые Foundation и VC allocations по distribution rules не имеют права голоса, но другие крупные holders сохраняют влияние.
FIP.16 получила 98,06% голосов «за» при majority condition 50%. Высокая поддержка не устраняет execution risk: изменения inflation contracts, fees, rewards и consensus builder внедряются разными releases.
Применение
Flare даёт DeFi приложениям native feeds и attestations внешних payments. FXRP используется в DEX, lending, vaults и liquid-staking products. FDC позволяет insurance, bridges и payment apps реагировать на события других chains.
FTSO может обслуживать markets за пределами crypto, но feed availability и legal rights на data нужно проверять. «До тысячи feeds» – capacity design, а не гарантия, что каждый рынок уже публикуется с нужной liquidity и качеством.
Основные риски
- Correlated data. Независимые providers могут использовать одинаковые exchanges, APIs или software.
- FAssets collateral. Price shock, liquidation delay или agent default может исчерпать buffer.
- Smart contracts. Asset Manager, pools, Core Vault и governance controller создают сложную поверхность атаки.
- External-chain risk. Reorg, congestion и destination-tag error на XRP Ledger влияют на mint и redemption.
- Role concentration. Одни entities могут одновременно быть validators, FTSO и FDC providers.
- Version confusion. Songbird tests, FXRP v1.2 и planned v1.3 нельзя смешивать с production.
- Token dilution. Даже сниженная target inflation размывает holders без rewards, если burns недостаточны.
- Governance execution. FIP.16 состоит из немедленных и будущих компонентов, включая ещё не завершённые consensus changes.
Итог
Flare объединяет EVM execution, consensus и data provision в одной economics. FTSOv2 даёт быстрые feeds, FDC подтверждает внешние события, а FXRP уже превращает XRP в composable EVM asset через agents и overcollateralization.
Сила проекта – согласованный data stack. Главный риск – та же связанность: validator, oracle, attestation и FAsset failures могут усиливать друг друга. FLR получает gas, security, governance и collateral demand, но итоговая tokenomics зависит от phased FIP.16, network revenue и способности burns догнать issuance.
