Flare Registry

A self-service registry for FTSO signal providers on Flare and Songbird. Live at flareregistry.com. Built by Burst Labs.

A provider connects the wallet for their on-chain address, signs a challenge to prove they control it, and manages their own listing. The result is published as a providerlist.json feed that is compatible with the standard provider-list schema, so any wallet that reads that list can read Flare Registry unchanged.

Only addresses registered on-chain as FTSO signal providers (on Flare or Songbird) can list, so the registry only ever contains real providers. The whole codebase, including the qualification rules that decide listing, is open source here for anyone to audit and reproduce.

Reading the feed: CONSUMERS.md. Why the registry exists: flareregistry.com/why.

Highlights

• Self-service listing. Sign in with your wallet and edit your listing instantly; it appears in the feed right away.
• Cryptographic ownership. A listing is editable only by the wallet that signed for its address.
• Live on-chain metrics. Fee, vote power, feed coverage, and per-epoch rewards, sourced from Flare's published reward data (flare-foundation/fsp-rewards).
• Transparent, automatic qualification. A Qualified status is computed automatically from on-chain data, with every criterion shown as a pass/fail.
• Registered providers only. Listing requires an on-chain registered FTSO address, so the registry cannot be polluted with arbitrary addresses.
• Checkable by the reader. The feed names a published JSON Schema, and every entry carries the SHA-256 of its logo, so a consumer can validate the document and confirm the image it serves is the one we published rather than taking either on trust.
• Open source and auditable. The listing logic is code anyone can read. Open, documented API plus a stable feed URL. See /api.

Qualification

Each provider is evaluated against an automatable set of trust and availability criteria, sourced from Flare's published reward data:

• Address on website (required for new providers; waived for established ones by on-chain tenure)
• Submitting prices (active in the latest reward epoch)
• Sufficient vote power (enough weight to participate in the signing policy)
• >=95% uptime over 30 days (present in at least 95% of the last ~9 reward epochs)
• One provider per network (a single registered entity per network)

A provider is Qualified when all automatable checks pass. Qualification latches: once earned, a provider stays qualified, and the only way to lose it is to stop submitting prices for 60 days (~17 epochs), after which it must re-qualify from scratch. The feed exposes how close a provider is to revocation (qualification.epochsUntilRevoke).

Items that cannot be verified on-chain (private node, in-house/open-source algorithm) are provider-attested and shown labeled as self-declared. Independence / no-collusion is not auto-judged; Qualified is a performance and identity signal, not a sybil guarantee.

How ownership verification works

1. The provider enters the on-chain address they want to claim.
2. The server issues a one-time challenge (a SIWE message containing a nonce).
3. The provider signs it with the wallet for that address.
4. The server recovers the signer and confirms it equals the claimed address before saving.

Sign in with your identity address (any of the five registered addresses is accepted, but the identity address gives the strongest on-chain match). On Flare and Songbird the address must be a registered on-chain FTSO entity; the testnets (Coston, Coston2) are exempt since they have no reward data to check against. The feed exposes all five of an entity's registered addresses under flareregistry.entity (identity, submit, submit-signatures, signing-policy, delegation).

Supported chains

Network	chainId
Flare	14
Songbird	19
Coston	16
Coston2	114

Endpoints

• GET /api/feed/providerlist.json — the wallet-compatible feed. Also published as a static file at raw.githubusercontent.com/BurstLabs/flareregistry/main/providerlist.json.
• GET /providerlist.schema.json — the JSON Schema that feed conforms to, named in its $schema. Checked against the generator on every build, so it cannot fall behind the document.
• GET /api/v1/providers — the same data in a versioned envelope.
• GET /api/feed/validators.json, /api/feed/yield.json — validator stats and delegator yield.
• GET /api/feed/coston2/providerlist.json, /api/feed/coston2/yield.json — the test network.
• GET /api/provider/:address — a single provider profile.
• POST /api/auth/nonce, POST /api/auth/verify — sign-in.
• POST /api/provider, POST /api/provider/logo — manage a listing (authenticated).

How to read it, including what listed and status mean and what not to infer from them: CONSUMERS.md. Field-by-field reference: /api.

A provider that stops submitting is not removed from the feed. It keeps its entry with listed: false and status: "departed", because the chain still carries its registration and a consumer still needs a name for it. /api/feed/archived.json, which used to hold those entries separately, was removed on 5 November 2026.

Logo assets

Logos are committed for the provider on upload and served from GitHub's raw CDN, keyed by the EIP-55 checksummed address: assets/<checksumAddress>.png. Square PNG, 128-256 px per side, <= 24 KB, enforced on upload and applied to mirrored images too. Transparency is recommended and not required; an opaque mark is a valid logo.

This is the beginning of the README. Read the rest at the original. Read the full README ↗