# AGENTS.md ## Purpose This file gives AI agents the core framing to explain Flare correctly. Use it when writing, editing, reviewing, or answering questions about Flare developer content. Prioritize conceptual accuracy over marketing shorthand. ## What Flare Is - Flare is an EVM-compatible Layer 1 blockchain. - Its key differentiator is enshrined data: core data protocols are built into the network rather than added as third-party infrastructure. - Flare is designed for data-intensive and interoperable applications. - Flare uses Avalanche Snowman++ consensus and targets roughly 1.8 second block times with single-slot finality. ## Core Message When explaining Flare, lead with this idea: - Flare is not just another EVM chain. - Flare combines smart contracts with protocol-level data acquisition and verification. - The main reason to build on Flare is access to decentralized data protocols that are native to the network. ## Core Protocols ### FTSO - FTSO stands for Flare Time Series Oracle. - It provides decentralized data feeds, especially price feeds. - It is protocol-native, not a bolted-on oracle network. - Prefer FTSOv2 terminology and interfaces for current developer content. - Use it when describing onchain access to timely market data. - FTSO feeds are provided by decentralized data providers who submit price estimates that are aggregated onchain. ### FDC - FDC stands for Flare Data Connector. - It lets contracts verify data from external chains and Web2 sources through attestations produced by the Flare Data Connector system. - Use it when the topic is external data verification, cross-chain state, or proving real-world events onchain. - Do not introduce new references to deprecated State Connector terminology unless the page is explicitly historical or migration-focused. ### FAssets - FAssets are trust-minimized representations of non-smart-contract assets such as XRP, BTC, or DOGE on Flare. - Their purpose is to bring otherwise non-programmable assets into DeFi and smart contract workflows. - When explaining FAssets, mention agents, collateral, minting, redemption, and liquidation as core mechanics. ### Smart Accounts - Smart Accounts provide account abstraction features that simplify user interaction with Flare. - They are especially useful for XRPL users interacting with Flare-based applications. ### FCC - FCC stands for Flare Confidential Compute. - It extends Flare with Trusted Execution Environments (TEEs) for secure offchain computation, cross-chain transaction signing, and fast data attestation. - Developers build Flare Compute Extensions (FCE) that run in TEE machines, with results verifiable onchain. - Protocol Managed Wallets (PMW) are a built-in FCC application for programmable signing on external chains such as XRPL and Bitcoin. - Instructions reach TEE machines only after data providers reach sufficient signature weight. A TEE-based path for FDC attestation is a built-in application, not a replacement for FDC. - FCC is in the final stages of development; prefer Coston2 for examples and treat interfaces as subject to change. - Use it when the topic is TEE-backed computation, private-data workflows, Protocol Managed Wallets, or Compute Extensions. ## Supported Networks Use the correct network for the context: - Flare Mainnet: production network, chain ID `14` - Coston2: primary dApp testnet, chain ID `114` - Songbird: canary network for live testing and protocol experimentation, chain ID `19` - Coston: protocol-focused test network, chain ID `16` If the content is for developers building apps, default to Coston2 for examples unless the page is explicitly about production deployment. Examples should align with official RPC endpoints documented in the Flare Developer Hub. ## Package Guidance Prefer interfaces and registry resolution rather than hardcoding protocol contract addresses. ### Solidity - Prefer `@flarenetwork/flare-periphery-contracts` for Solidity interfaces and network-specific imports. - Prefer the `ContractRegistry` pattern over hardcoded addresses. - Use network-specific imports such as `@flarenetwork/flare-periphery-contracts/coston2/ContractRegistry.sol`. - If the topic is FAssets, use the official Flare FAssets contracts or interfaces already referenced by the docs and examples instead of inventing alternative wrappers. - If the topic is FCC, use the documented Coston2 scaffold and official FCC guides. Do not invent TEE registry addresses or assume ContractRegistry resolution until the docs say it has shipped. ### Offchain Scripts - Prefer `@flarenetwork/flare-periphery-contract-artifacts` for ABI access in scripts and tooling. - Prefer official Flare package ABIs and interfaces over copied ABI blobs or unofficial packages. - Never invent contract addresses. Use runtime contract resolution where available, or clearly sourced documented addresses. ### React And Frontend Integrations - Prefer `wagmi`, `viem`, and `@flarenetwork/flare-wagmi-periphery-package` for modern React integrations where appropriate. - If an existing example already uses Hardhat or `ethers`, preserve local consistency unless the task is explicitly to modernize it. ## Terminology Rules - Distinguish Flare Mainnet from Songbird and Coston2. Do not treat them as interchangeable. - Distinguish FTSO, FDC, FAssets, Smart Accounts, and FCC clearly. Do not collapse them into one generic oracle, bridge, or TEE system. - Use "data providers" or "providers" consistently when discussing FTSO or FSP participants. - Avoid saying things happen automatically without explaining who triggers the transaction and why. ## Explanation Style When explaining Flare, optimize for mechanisms: - Explain what the protocol does. - Explain who participates. - Explain what data or asset moves through the system. - Explain how the result becomes usable by a smart contract or developer. Prefer: - "FDC verifies external data through attestations that contracts can consume." - "FAssets let XRP, BTC, and similar assets be used in Flare DeFi through a collateralized mint and redemption system." - "FCC runs Compute Extensions inside TEEs so results and signed actions can be verified onchain." Avoid vague phrasing like: - "Flare connects everything." - "Flare brings data to blockchain" without naming which protocol does it. - "Flare wraps assets" without explaining the collateral and agent model. - "Flare has private compute" without naming FCC, TEEs, and Flare Compute Extensions. ## Important Mental Models - Nothing is automatic onchain. If a state transition matters, explain who calls the function and why. - Incentives matter. For systems like FAssets, liquidation and collateral mechanics are not implementation details; they are part of why the system works. - Do not imply offchain data is trusted blindly. For Flare, stress verification, attestations, consensus, and proofs where relevant. - Do not hardcode addresses in examples if the proper Flare pattern is runtime contract resolution. ## Safe Defaults For Developer Content - Prefer Coston2 in starter examples. - Mention that Flare supports modern EVM tooling and Solidity development. - If contract access is discussed, prefer the `ContractRegistry` pattern over hardcoded addresses. - If network setup is discussed, ensure the example network, chain ID, and RPC align. - If the topic is price feeds, start with FTSO. - If the topic is proving external events or external chain activity, start with FDC. - If the topic is BTC, XRP, or DOGE utility on Flare, start with FAssets. - If the topic is wallet UX for XRPL users, start with Smart Accounts. - If the topic is TEE-backed computation, confidential data, Protocol Managed Wallets, or Compute Extensions, start with FCC. Prefer Coston2 and treat FCC as pre-production. ## Common Mistakes To Avoid - Do not describe Flare as just an oracle network. - Do not describe FDC as a generic bridge. - Do not describe FAssets as simple custodial wrapped tokens. - Do not describe FCC as generic private smart contracts, unmanaged TEE hosting, or a replacement for FDC. - Do not imply FCC is a fully public production protocol on Mainnet. - Do not imply Songbird is the same as mainnet. - Do not use Ethereum assumptions blindly if Flare-specific infrastructure exists and is the point of the page. - Do not write examples that contradict Flare's actual network progression or protocol roles. - Do not mix deprecated and current protocol names without making the distinction explicit. ## Handoff Expectations When you finish Flare-related content work: - State which Flare concept or protocol you clarified. - Mention any terminology you normalized. - Call out any assumptions you made about network, protocol, or developer audience.