Layer 1 blockchain
Flare ticker FLR
Summary
Flare Mainnet, live since July 2022, runs go-flare, which Flare describes as a modified version of AvalancheGo. Snowman++ consensus runs on two chains: the P-chain, where validators register and FLR is staked, and the C-chain, where accounts and EVM smart contracts live. Any node becomes a validator by locking a self-bond of at least 1M FLR on the P-chain for at least two months; holders can delegate from 50K FLR. Validators poll stake-weighted samples of other validators and accept a block after repeated agreeing polls, and Flare's docs treat an accepted block as final. Staking rewards also require running a Flare Entity, which supplies data to the FTSO feeds and the Flare Data Connector. A P-chain API read on 2026-09-29 listed 180 validators with about 22.9B FLR of self-bond and delegation; the 30 largest nodes held over a third of it. 1241420222324
Design
- System
- Layer 1 blockchainIndependent proof-of-stake chain with its own validators; it does not settle to another chain. Its node software, go-flare, is a modified version of AvalancheGo, and smart contracts run on the EVM on its C-chain. Songbird (chain ID 19, token SGB) is a separate network that Flare calls its canary network, where protocol changes are trialled before Flare Mainnet; this profile covers Flare Mainnet (chain ID 14) only.
- Settlement family
- Its own design
- Scarce resource
- Stake (proof of stake)
- State model
- Accounts
- Finality
- Other
- Who makes blocks
- At each height Snowman++ samples six validators by stake and gives each a waiting time set by its position, in five-second windows, before it may propose a block. The proposer sets transaction order, by default a priority gas auction. FIP.16, accepted in April 2026, lays out stages that hand block building, and later block proposing, to one governance-designated entity, initially the Flare Foundation; whether any stage is live was not verified.
- Fork choice
- No longest-chain rule weighted by work or stake. Each validator keeps a preferred branch and changes it only after repeated polls of stake-weighted validator samples favour another; a vote for a block also counts for its ancestors that are not yet final. Flare's docs describe Snowman++ as a Byzantine fault tolerant protocol within a family of probabilistic protocols.
Qualifications
- Settlement family · Partial. Recorded as other. Flare's own terms: go-flare, a modified AvalancheGo node, runs Snowman++ on a P-chain for validator registration and staking and on a C-chain whose EVM holds accounts and contracts, with Flare additions (a daemon contract the node invokes and prioritised contract handling) that serve the Flare Systems Protocol. The C-chain uses Ethereum's account and transaction formats and works with Ethereum wallets, so readers can reasonably place it either way.
- Finality · Partial. Recorded as other. Flare's own terms: single-slot finality; once a block is accepted through the consensus process it is considered final. Acceptance comes from repeated stake-weighted sampled polls (Snowball instances inside Snowman++), which Flare's docs place in a family of probabilistic protocols, and no rule that removes bonded stake for misbehaviour was found.
- State model · Partial. The account model describes the C-chain, where users hold FLR and contracts run. The P-chain keeps validator, self-bond and delegation records, and moving FLR between the two chains takes an export on one side and an import on the other; the P-chain's own record format is not characterized in this profile.
- Enshrined data protocols · Contested. Flare calls the FTSO and the Flare Data Connector enshrined, and its terminology page says an enshrined component must need a hard fork to change. The reviewed docs show feeds added or delisted, attestation types and sources added, and parameters adjusted through Management Group votes and contract redeployments under governance, FIP.12 states that enabling the Flare Data Connector did not require a hard fork, and the node's own role is invoking a daemon contract and prioritising contract handling. Both readings are recorded.
- Data protocol security · Partial. FTSO and FDC results are confirmed when data providers holding over half of the signing weight sign a Merkle root (60% after delays), a vote separate from block consensus. Signing weight comes from P-chain stake and WFLR delegations, with delegations capped at 2.5% of WFLR supply per provider, so the same staked FLR backs both, but the two votes are distinct.
- Slashing · Unknown. Flare's docs describe penalties as withheld or burned rewards (for example below 80% uptime, or for late signing) and, for data providers, chilling or banning by the Management Group. No rule that removes bonded stake was found; Ledger's Flare coin page says data providers' stake can be slashed, which the reviewed Flare docs do not describe. Absence was not exhaustively verified.
Tradeoffs
- Emphasizes
- Scalability
- Gives up
- Open, independent block production. A validator needs a 1M FLR self-bond, and staking rewards also require running Flare Entity data-provider services, which the docs size at 16 cores, 64 GB of RAM and 4 TB. The Flare Foundation initiates every governance proposal and, under FIP.16, is to be the single block builder at first. In a 2026-09-29 P-chain read, stake was spread over 180 nodes, but grouped by the address that receives validation rewards 17 groups held over a third, and who operates them was not verified.Security is not listed as an emphasis: the reviewed docs penalize validators and data providers by withholding or burning rewards, chilling or banning, and no rule that removes bonded stake was found. Flare's docs present fast single-slot finality and data feeds backed by the whole network's stake as design goals; readers who count that as a security design may reasonably disagree. Delegation was broad in the 2026-09-29 read (about 5,700 distinct delegator reward addresses, the largest with about 2.5% of delegated stake), but addresses are not people.
- Full node at home
- Practical at home 1131420Flare's docs list 4 CPU cores, 16 GB of RAM and a 1 TB SSD for a pruned mainnet node (5.7 TB for an archive node, growing about 30 GB a month), disks reaching 1200 MB/s read and 600 MB/s write, and 40/10 Mbps, with Ubuntu LTS the most tested system. New nodes bootstrap through three listed bootstrap nodes, one on Flare's domain and two on infrastructure providers' domains. A validator adds a 1M FLR self-bond, and full rewards need a Flare Entity sized at 16 cores, 64 GB of RAM and 4 TB.
- Throughput claims
- No classified figure recorded
Scaling layers
No scaling layer recorded in this profile.
Capabilities
| Capability | How it is provided | Notes and sources |
|---|---|---|
| Account abstraction | Structured assessment pending | Not yet assessed for any chain. |
| Atomic swaps | Unknown | No hash-time-locked or other trust-minimised swap mechanism running on Flare Mainnet was reviewed. EVM contracts and the Flare Data Connector's payment and payment-nonexistence attestations are building blocks for one; FAssets is a collateralised bridge and is recorded under bridges. 78 |
| Authenticated data publication | Unknown | Not assessed. The Flare Data Connector stores each round's Merkle root of attestation responses in the Relay contract once providers holding over half of the signing weight sign it, and anyone can fetch responses and proofs from a Data Availability Layer and check them against that root. What is attested is chosen by data providers verifying requested facts about other chains, not published by a data owner, so whether it meets this row is left for review; FTSO feeds are oracle values. 467 |
| Light clients | Unknown | Flare's docs point to example Go code for checking block headers and bodies and say a transaction can be checked with Merkle Patricia proofs against a block's receipts root. These are building blocks; no light client that checks validator agreement was found. 1 |
| Native staking or delegation | Structured assessment pending | Not yet assessed for any chain. |
| On-chain governance | Structured assessment pending | Not yet assessed for any chain. |
| Parallel execution | Structured assessment pending | Not yet assessed for any chain. |
| Payment or state channels | Unknown | No payment or state channel layer anchored to Flare was found in the reviewed sources. |
| Programmable spending | Native (protocol or core-team software) Earlier definition | Smart contracts on the C-chain's EVM set spend conditions; Flare's docs say contracts in Solidity, Vyper and other EVM languages deploy directly. WFLR, used for delegation and voting, is FLR wrapped in the WNat contract. 134 |
| Protocol-verified messaging | Structured assessment pending | Not yet assessed for any chain. |
| Reversible transfers or recovery | Unknown | Not yet assessed under the current definitions. Flare's network page lists a Safe multisig deployment for mainnet, where a set number of owners approve each spend, but no delay or recovery module deployed on Flare was shown, and an owner threshold alone meets neither part of this row. 1 |
| Rollups | Unknown | No rollup or validium settling to Flare was found in the reviewed sources; absence was not exhaustively verified. |
| Shielded transfers | Structured assessment pending | Not yet assessed for any chain. |
| Signed partial offers | Unknown | Not yet assessed under this row's current definition. |
Reading these values
- How this feature is provided
- Built into the protocol, core-team software or independent software says where a feature lives and who can change it. These are implementation layers, not quality: core-team software is not closer to the protocol than independent software.
- Structured assessment pending
- The shared review has not assessed this feature for any chain yet (Account abstraction, Native staking or delegation, On-chain governance, Parallel execution, Protocol-verified messaging and Shielded transfers). That does not mean it is absent, and a chain’s profile may already describe it.
- Unknown
- The review has not established this for this chain under the current definition; the note beside it says why. Unknown is not absent and not a low score. A feature reads “Not present” only when a source shows it is absent.
- Earlier definition
- Payment or state channels, Programmable spending and Rollups keep the earlier definition until the next fact-check. There, “Native” does not separate the protocol from core-team software, “Ecosystem software” does not say who publishes it, and “Partial” does not say which layer.
- Reading across rows
- The list of capabilities is incomplete. Do not read these rows as a chain leading or lagging overall.
Ecosystem & custody
| Product type | Status | Notes and sources |
|---|---|---|
| Automated market makers | Established in the ecosystemSparkDEX, Ēnosys DEX, BlazeSwap | Flare's own FXRP swap guide uses SparkDEX's V3 swap router on mainnet. DeFiLlama's index lists SparkDEX, Ēnosys and BlazeSwap exchanges on Flare as separate projects. Operators' audits and liquidity depth were not reviewed; listing is not endorsement. 173738 |
| Issuer-native stablecoins | ThinCDP (Ēnosys Loans) | Ēnosys Loans mints CDP, which it calls a soft-pegged stable currency, against FXRP, stXRP, WFLR and sFLR collateral. Circle's USDC address list and Tether's supported-protocols list do not include Flare. USDT0 on Flare is a LayerZero token minted against USDT locked in a contract on Ethereum, and USDC.e arrives through Stargate; both are recorded under bridges. 16323334353637 |
| Algorithmic stablecoins | Unknown | No algorithmic stablecoin with material use on Flare was reviewed. Ēnosys Loans' CDP is backed by collateral positions, so it is listed with native stablecoins. 36 |
| Bridges | First-partyFAssets (FXRP from the XRP Ledger), LayerZero V2 and Stargate V2, USDT0 (LayerZero token) | FAssets, built by Flare, mints FXRP on Flare after the Data Connector verifies an XRP payment and redeems it back to the XRP Ledger through collateralised agents or the Core Vault; FXRP went live on mainnet on 24 September 2025. FBTC, FDOGE and FLTC appear only as token names in the reviewed docs. Flare's developer tools page lists LayerZero V2, Stargate V2 and USDT0, and FXRP moves to other chains as a LayerZero token. Risk: The XRP backing FXRP is held by agents in their own XRP Ledger accounts and in a Core Vault, a multisig account on the XRP Ledger whose signers Flare governance authorises and which is operated manually in daily windows; since v1.3, direct mints send XRP to that vault address, and direct user redemption from it needs KYC approval. Governance can pause FAssets operations up to freezing FXRP transfers, and minting is capped. LayerZero transfers depend on the verifier set each token's deployer configures. A wrapped asset is only as sound as the system that minted it. 89101112162339 |
| Block explorers | ThinFlare Explorer, Flare Systems Explorer | Flare's developer tools page lists the Flare Explorer, a Blockscout instance on a Flare domain whose public stats API answered on 2026-09-29, and a Systems Explorer for FTSO, FDC, data-provider and epoch data, without naming who runs either or calling either official. One general block explorer was seen serving data. Explorer data is indexed by its operator, not consensus. 1162527 |
| Hardware wallets | Established in the ecosystemLedger (C-chain in Ledger Wallet; P-chain through Flare's tools), Trezor (through MetaMask, Rabby or the Flare Portal) | See custody rows: Ledger's current wallet code enables Flare's C-chain by default and signs through the Ledger Ethereum app, but carries no P-chain entry, and Flare's stake tool supports Ledger devices for P-chain staking; Trezor's Flare page names MetaMask and Rabby and says Flare is not supported in the Trezor Suite app, and Flare's wallets page lists Trezor functions through the Flare Portal. 151928293031 |
Hardware-wallet custody
| Device maker | Status | What users can and cannot do |
|---|---|---|
| Ledger | PartialFlare's stake tool or the Flare Portal, for P-chain staking and Flare's wrapping, delegation and voting functionsSame as native: Unknown | Can: Add a Flare C-chain account in Ledger Wallet: current Ledger wallet code lists Flare (chain ID 14) among its EVM networks with no feature switch, so it is on by default, signing through the Ledger Ethereum device app Can: Stake FLR on the P-chain with a Ledger device through Flare's stake tool, which Flare's docs recommend and which uses the device's Avalanche app Can: Use a Ledger with the wrapping, staking, delegation, reward, voting and FAssets functions that Flare's wallets page lists for it Cannot: See or stake FLR on the P-chain in Ledger Wallet: Ledger's currency list and coin modules carry Flare only as an EVM network, and Flare's stake tool has users close Ledger Wallet before staking Cannot: Rely on Ledger's Flare coin page for protocol details: it still describes the State Connector, which FIP.12 replaced with the Flare Data ConnectorC-chain only in Ledger Wallet: Ledger's code has no Flare P-chain entry, so staking and P-chain balances are reached through Flare's own tools; this was read from code and not tested in the app. Ledger's coin page is a general template that also says data providers' stake can be slashed, which the reviewed Flare docs do not describe. Flare's wallets page labels Ledger's Flare functions, staking included, as in-app; Ledger's code does not show them. 15192627282940 |
| Trezor | Through an intermediaryMetaMask or Rabby (third-party wallet apps named on Trezor's Flare page), or the Flare Portal (Flare's web app, which Flare's wallets page lists for Trezor)Same as native: Unknown | Can: Sign Flare network transactions with a Trezor Safe 3, Safe 5 or Safe 7 through MetaMask or Rabby, the apps Trezor's Flare page names Can: Wrap, stake, delegate, claim and vote through the Flare Portal, the functions Flare's wallets page lists for Trezor Cannot: Manage FLR in Trezor Suite: Trezor's Flare page says Flare is not supported in the Suite app, and Suite's current network configuration has no Flare networkTrezor's Flare page also still describes the State Connector. The Flare Portal path is listed by Flare, not by Trezor, and was not tested, including whether its staking reaches the P-chain with a Trezor device. 193031 |
Public data
iKnow Blockchain has no public-data lookups for Flare yet. This is a limit of the service, not a statement about the network.
| Lookup | Status | What it covers and its limits |
|---|---|---|
| Address or account | Not available yet | Public-data lookups for this chain are not built yet. |
| Tokens and assets | Not available yet | Public-data lookups for this chain are not built yet. |
| NFTs | Not available yet | Public-data lookups for this chain are not built yet. |
| Transactions | Not available yet | Public-data lookups for this chain are not built yet. |
Sourced developments
Developments: Reviewed Sep 29, 2026 Next review due Oct 9, 2026, 12:00 UTC.
Publication date · newest first
-
go-flare v1.14.0 (Granite upgrade) schedules a 500 gwei fee floor and a 300M FLR validator cap
The Flare Foundation released go-flare v1.14.0, which moves the node to AvalancheGo v1.14.0 (the Granite upgrade) and schedules its changes for Coston on 11 June, Coston2 on 16 June, Songbird on 7 July and Flare Mainnet on 14 July 2026, each at 12:00 UTC. On Flare it raises the minimum C-chain base fee to 500 gwei, raises the maximum validator stake from 200M to 300M FLR, and sets a 20% minimum delegation fee for validators, previously 0%.
- Proposal:implements parts of FIP.16, accepted on 24 April 2026
- Implementation:shipped in go-flare v1.14.0
- Release:released 17 June 2026; a v1.14.2 release candidate in July schedules no new fork times
- Activation:scheduled for Flare Mainnet on 14 July 2026 at 12:00 UTC; validator stakes above the old cap fit activation, but no block was checked for the fee floor
Sources: Flare Foundation (GitHub) — go-flare v1.14.0 (external site) · Flare Foundation (GitHub) — Release Notes: Flare and Songbird networks (external site) · Flare Developer Hub — Register as Validator (external site) · Flare (flare-api.flare.network) — Flare P-chain API: platform.getCurrentValidators (read 2026-09-29) (external site) · Flare (flare-explorer.flare.network) — Flare Explorer API: network stats (read 2026-09-29) (external site) · Flare Governance Proposals — FIP.16: Restructure FLR Tokenomics for Long-Term Network Sustainability (external site)
-
FAssets v1.3 announced as live on mainnet, with direct FXRP minting
Flare announced that FAssets v1.3 is live on Flare Mainnet after an earlier Songbird deployment. Users now mint FXRP by sending XRP on the XRP Ledger to the FAssets system address with a destination tag, a memo or a Flare Smart Account instruction; an executor relays an FDC payment proof, and FXRP is minted without choosing an agent. Agents still handle redemptions under the existing collateral model, and v1.3 adds executor restrictions, hourly and daily mint caps, delays on large mints and a governance path to release delayed mints.
- Implementation:FAssets v1.3 deployed, per Flare's announcement
- Release:announced as live on Flare Mainnet on 28 April 2026
- Activation:live on mainnet per the April announcement, after a Songbird deployment; Flare's September 2026 post dates mainnet arrival to mid-May 2026 (not reconciled)
Sources: Flare — FAssets v1.3 is live: direct FXRP minting fits the rails XRP already uses (external site) · Flare Developer Hub — Core Vault (external site) · Flare Developer Hub — Flare Smart Accounts (external site) · Flare — One year of FXRP on Flare (external site)
-
FIP.16 accepted: lower FLR inflation, a higher base fee floor and a single block builder roadmap
Flare holders accepted FIP.16, written by the Flare Foundation, with 98.06% of votes cast in favour. It sets annual FLR inflation at 3% (down from 5%) with a 3 billion FLR yearly cap, raises the minimum base fee from 25 to 500 gwei, raises the base FDC request fee for most attestation types from 1 to 20 FLR, sends most FDC fees and part of FAssets fees to new FIRE pools, gives P-chain stake five times the weight of WFLR delegations in data-provider signing weight, sets a 20% minimum entity fee, raises the per-validator stake cap to 300M FLR, and lays out stages that move block building, then proposing, to one governance-designated entity, starting with the Flare Foundation.
- Proposal:accepted on 24 April 2026
- Implementation:fee floor, stake cap and minimum delegation fee shipped in go-flare v1.14.0; Flare reports the first emissions cut executed in mid-May 2026; FDC fee, FIRE and signing-weight changes not verified
- Release:hard-fork parts released in go-flare v1.14.0 on 17 June 2026
- Activation:hard-fork parts scheduled for Flare Mainnet on 14 July 2026; inflation cut reported by Flare as executed, not checked on chain; block-builder stages not verified as active
Sources: Flare Governance Proposals — FIP.16: Restructure FLR Tokenomics for Long-Term Network Sustainability (external site) · Flare Foundation (GitHub) — Release Notes: Flare and Songbird networks (external site) · Flare Foundation (GitHub) — go-flare v1.14.0 (external site) · Flare — One year of FXRP on Flare (external site)
-
FIP.14 accepted: Web2Json attestations for the Flare Data Connector, with no mainnet source at review
Flare holders accepted FIP.14 with 94.66% of votes cast in favour. It adds Web2Json, an FDC attestation type that fetches JSON from approved web APIs and returns processed values to contracts, and a process in which users propose API sources, the Flare Foundation vets them and the Management Group votes on each source and on fee changes. At review, Flare's docs said Web2Json had no configured source on Flare Mainnet or Songbird, so requests for it revert; it remains available on the Coston and Coston2 testnets.
- Proposal:accepted on 5 December 2025
- Implementation:attestation type implemented; no Flare Mainnet source configured at review
- Release:available on the Coston and Coston2 testnets
- Activation:not usable on Flare Mainnet at review: requests revert
Sources: Flare Governance Proposals — FIP.14: Add Support for FDC Web2 Attestations (external site) · Flare Developer Hub — Web2 FDC Setup (external site) · Flare Developer Hub — Flare Data Connector (FDC) (external site)
Topics your AI can explain
Your AI can explain these topics for Flare through the connection, with sources.
Known gaps
What this profile's review did not establish:
- Who operates the 180 validator nodes was not identified; grouping by the address that receives validation rewards is only a rough proxy for operators, and one entity may run up to four validators.
- How much of the P-chain self-bond and delegation belongs to the Flare Foundation or its affiliates, including any remaining stake boosting, was not verified.
- Whether any stage of FIP.16's single block builder plan is live on Flare Mainnet was not verified.
- Flare's validator registration page still gives a 200M FLR maximum stake per validator, while go-flare v1.14.0's notes raise it to 300M FLR from 14 July 2026 and the P-chain read showed 46 validators above 200M FLR and a largest total of about 300M FLR.
- Flare's docs give a block time of about 1.8 seconds; the explorer's stats reported an average of about 1.07 seconds on 2026-09-29. The two were not reconciled.
- No throughput figure with a method was found in Flare's reviewed documentation, so no throughput claim is recorded.
- The number of active data providers and the distribution of their signing weight were not read; the Systems Explorer renders only in a browser.
- No rule removing bonded stake was found; absence was not exhaustively verified, and slashing is marked unknown.
- Mainnet status of FBTC, FDOGE and FLTC was not verified; only FXRP has documented mainnet parameters.
- The identities of the Core Vault multisig signers and the terms of their agreements with Flare governance were not reviewed.
- The P-chain's record format was not characterized.
- That Ledger Wallet does not show P-chain balances or stakes is read from Ledger's code, which carries Flare only as an EVM network, and was not tested in the app; whether the Flare Portal's staking works with a Trezor device was not verified.
- No atomic swap, recovery feature, light client, channel layer or rollup on Flare was found; absence was not exhaustively verified.
- Flare's September 2026 anniversary post says the first FIP.16 emissions cut was executed in mid-May 2026; the on-chain inflation settings, FDC fee changes, FIRE pools and signing-weight changes were not checked.
- Flare's April 2026 announcement says FAssets v1.3 is live on mainnet, while its September 2026 anniversary post places v1.3 reaching mainnet in mid-May 2026; the two dates were not reconciled.
- Exchange operators' audits and liquidity depth were not reviewed.
Sources
Oldest dated source check: Source checked Sep 29, 2026 Next check due Oct 29, 2026.
- Network: configuration, transaction format, smart contracts and consensus mechanism (external site)
- Consensus (Snow family, Snowman and Snowman++) (external site)
- Governance (external site)
- Flare Systems Protocol: Weights and Signing (external site)
- Flare Systems Protocol: System Protocols (external site)
- FTSOv2 overview (external site)
- Flare Data Connector (FDC) overview (external site)
- FAssets overview (external site)
- FAssets Core Vault (external site)
- FAssets Emergency Pause System (external site)
- FXRP Operational Parameters (external site)
- FXRP as an Omnichain Fungible Token (LayerZero) (external site)
- Check System Requirements (node hardware) (external site)
- Register as Validator (staking phases and stake requirements) (external site)
- Using Flare Stake Tool (external site)
- Developer Tools (bridges, wallet SDKs, explorers) (external site)
- Swap USDT0 to FXRP (SparkDEX V3 router on Flare Mainnet) (external site)
- Terminology (canary, enshrined oracle) (external site)
- Flare Wallets (external site)
- go-flare README (modified AvalancheGo for Flare and Songbird) (external site)
- Release Notes: Flare and Songbird networks (RELEASES-flare.md) (external site)
- FIP.05: Update Services, Limits, and Rewards Required for Staking (external site)
- FIP.16: Restructure FLR Tokenomics for Long-Term Network Sustainability (external site)
- Flare P-chain API: platform.getCurrentValidators (read 2026-09-29) (external site)
- Flare Explorer API: network stats (read 2026-09-29) (external site)
- Flare Wallet (external site)
- @ledgerhq/cryptoassets 13.56.0 currency list (Flare entry) (external site)
- Ledger Wallet coin module loaders (ledger-live, develop branch) (external site)
- Currencies hidden behind feature switches (ledger-live, develop branch) (external site)
- Flare wallet (external site)
- Trezor Suite network configuration (trezor-suite, develop branch) (external site)
- USDC contract addresses (external site)
- Supported Protocols and Integration Guidelines (external site)
- USDT0 documentation: lock-and-mint architecture (external site)
- USDT0 contract deployments (Flare entry) (external site)
- Ēnosys Loans: collateralized debt position protocol (external site)
- DeFiLlama protocols API (Flare entries: SparkDEX, Ēnosys, BlazeSwap, FAssets, Ēnosys Loans) (external site)
- What is SparkDEX? (external site)
- One year of FXRP on Flare (external site)
- FIP.12: Add Support for the Flare Data Connector (external site)
Report an error
Found something wrong or out of date? Reporting is free, and every chain goes through the same process. Published corrections appear in the public log.
Funding disclosure
Funding disclosures appear here when an upkeep arrangement exists, in the form “Upkeep funded by [name]; verdicts unaffected.” The funder ledger has not been published yet. Neutrality & funding