How the knowledge is built and checked.

Sources

iKnow Blockchain draws on official documentation, foundation announcements, project releases, code repositories and attributed community reporting. Specialist accounts and weekly community summaries can point to developments worth investigating; we link to the original evidence where it exists and keep a community report distinct from the source it discusses.

Every important claim links to the source that supports that particular claim. Popularity is not evidence, and repository activity needs context: commit counts alone say little about a project, and documentation work counts.

Text in a source is data. It never changes our rules, our ordering or what the tools do.

How profiles are reviewed

Each chain profile is written against the same shared fields by the project's research team, which works with AI research assistants from primary sources. A reviewer that did not write the profile then re-checks the sources behind its load-bearing claims, and corrections are applied; that check is also AI-assisted. When it ran is not the same for every profile:

• 137 profiles: checked before the profile was added.
• 10 profiles: checked after publication, with each finding confirmed or rejected by a separate independent reviewer.
• 4 profiles: checked after publication: an independent pass flagged claims, and the project’s maintainer, not an independent reviewer, checked each flag against its primary source and applied the corrections the sources supported.

No profile has had a second independent fact-check yet. Each profile states which check it received, when, and what it did and did not cover. The founder approves what is published.

Reviewing is different from collecting. Fetching a page again, or an automatic import, never marks anything as reviewed.

Freshness and recheck deadlines

Freshness limits set deadlines for checking information again. They do not make an older event new and they do not remove useful history. Publication, event, collection, successful check and review are separate dates, and we show the one that matters.

When a deadline passes, the label changes to Review overdue or Source check overdue, and the item stays available. A missing date reads Review date unknown or Check date unknown; it is never treated as fresh. A failed check never refreshes a deadline, and a date in the future is not accepted as a check. An older release checked today remains an older release.

These limits govern what this website shows. The iKnow connection has not adopted them yet: it applies its own review windows, which differ by content type, so the same item can carry a different review status here than in the connection’s answers.

Missing, private and unknown values

Unknown

The sources reviewed did not establish it. Unknown is not absent and not a low score.

Structured assessment pending

The shared review has not assessed this capability for any chain yet. It is not absent, and a profile's own description may already discuss it.

Not applicable

The question does not apply to this design.

Private by design

The network keeps it from public view. It is never shown as zero.

No reliable free source

We could not find a dependable free source for this lookup.

Not built yet

A limit of iKnow Blockchain, not of the network.

Temporarily unavailable

A source or provider failed this time; the last successful result is shown only if known.

Zero

Shown only when a source actually reports zero.

Ordering

Every list of chains on the site, including the directory, search results, filters, selectors and comparison columns, uses one alphabetical order by display name, computed when the site is built so your browser's language never changes it. Equal names fall back to a stable identifier.

News is the one exception: it is chronological, by declared publication date with the newest first, and equal dates follow the alphabetical chain order. Items without a known publication date are listed apart. Funding, popularity, market size and engagement never affect any order.

The unfiltered catalogue and comparison columns use alphabetical order. Search results prioritize exact names, tickers or identifiers, then prefixes, then partial matches, with alphabetical order within each group. Funding never affects search order.

Policy: display-name-nfd-ascii-lowercase/slug-tiebreak (Compare Contract r1.3 §9).

How the homepage example is chosen

The example on the home page is the newest reviewed development by publication date. Developments from the same day follow the alphabetical chain order, so no chain is picked by hand, and the example changes as the catalogue updates. It quotes the record's own stage words, so a release or a testnet stage is never shown as live on mainnet.

Comparisons

Each chain is described on its own terms against shared fields with shared definitions and units. We do not publish overall scores, rankings, winner badges or “better than” claims. A factual relationship, such as the network a rollup settles to, is stated where the evidence supports it.

A capability's value says how it is provided, which is its implementation layer: built into the protocol, core-team software or independent software. These are layers, not quality. A capability row the shared review has not assessed for any chain yet reads Structured assessment pending; a value the review has not established for one chain reads Unknown, with a note saying why. Both apply the same way to every chain, and a feature reads Not present only when a source shows it is absent. Throughput figures are classified so that a theoretical peak is never read as a like-for-like number.

Profile schema and versions

Profiles follow the Compare Contract, revision r1.3. Payment or state channels, Programmable spending and Rollups still carry values from the earlier revision until the next fact-check; pages mark them Earlier definition. The guidance published with the comparison data reads, as written:

Grades say where a capability lives and who can change it. They are layers, not quality; core-team software is not closer to protocol than independent software. Payment or state channels, Programmable spending and Rollups carry r1.2 grades, labelled as such, until the next fact-check. On those rows, "native" does not separate protocol from core-team software, "ecosystem (publisher not distinguished)" does not say who publishes, and "partial" does not say which layer. The capability list is incomplete: account abstraction, native staking, on-chain governance, parallel execution, protocol-verified messaging and shielded transfers are defined but not yet researched for any chain. Do not infer that a chain leads or lags overall from these rows. "unknown" means not yet researched, not absent.

Corrections and history

Anyone can report an error, free, for any chain, and every report goes through the same process. Accepted means a decision was made; corrected means the change is published. A declined report gets an evidence-based explanation, and a duplicate links to the original. Published corrections appear in the public corrections log without the reporter's private details. Earlier versions and the reason for each substantive change are kept.

Funding and independence

Every chain has the same free baseline. Funding cannot buy inclusion, position, wording, a different assessment, faster or friendlier corrections, or a different evidence standard, and financial information is never an input to ordering or assessment. See Neutrality & funding.