Method
Shippeth gathers releases, blog posts and security advisories from a fixed list of Ethereum projects and of the software node operators run beside them, orders them by the rules described here, and links every entry back to its origin with the excerpt quoted word for word.
What never appears
- Nightly builds, snapshots and unstable channels.
- A prerelease whose version number gives no hint of its contents. When the number marks a candidate, a beta, an alpha or a preview, the entry moves to release candidates instead. A handful of projects ship only prereleases, and the register notes that beside the source so their work still appears.
- Drafts.
- Work a source published about a chain outside Ethereum. Auditing firms and infrastructure teams take on whoever hires them and post every report to one feed, and an audit of a TRON library once topped this page on the reputation of the firm alone. The flag that drops such pieces is set by hand on those few sources, because almost everywhere else a rival chain in the headline still marks Ethereum coverage: Starknet explaining how it bridges Bitcoin, Erigon announcing that it will drop BNB Smart Chain, the Ethereum Foundation taking apart Bitcoin maximalism. Any headline that also names Ethereum or one of its layers keeps the entry.
- A post a publisher files under a section we do not follow. Company blogs mix product news with sports betting, market commentary and evergreen guides, and we drop those by the publisher’s own category labels rather than by reading the headline, which would also have thrown out “How to Create and Validate EIP-4844 Blob Transactions”. A news outlet works the other way round, where we name the one desk we want and let the rest fall away, so a market column that mentions a bill in passing never arrives as policy coverage. A headline naming Ethereum comes in under whatever desk filed it. The labels that apply to each source live in the register the collector reads.
How ranking works
The ranking measures quality in hours of head start. An entry sits in the order as though it had appeared that many hours later than it really did, so a release worth three days of head start keeps ahead of the fresh minor releases around it for three days and then drifts down as it ages. Time and quality set the whole order between them, with no decay curve to tune and no separate term for recency.
Publication time is rounded down to a six-hour window before anything else, so entries from one window rank as equally old and quality alone tells them apart. Left unrounded, an hour of freshness bought an hour of quality outright, and a trivial release from ten minutes ago outranked a substantial one from the morning. The window runs to six hours and not twelve because two entries three hours apart can land on opposite sides of a boundary, which at twelve hours forced them as far as eleven hours apart; at six the widest gap measured over sixty days came to two.
| Component | Hours |
|---|---|
| Network-critical project (clients, specs) | +36 |
| High-weight project | +24 |
| Everything else | +6 |
| Article rather than a release | +30 |
| Major version | +48 |
| Minor version | +12 |
| Patch version with no urgency wording | −30 |
| An instalment of a column running to twelve parts or more | −24 |
| Source says “security” | +96 |
| Security advisory, exploited vulnerability or trust incident (see below) | +96 |
| An advisory with the outcome of three days in CISA’s table | +36 |
| Source grades the release high or critical | +72 |
| Source grades the release medium | +12 |
| Source says “recommended” or “required” | +48 |
| Source says “breaking” | +36 |
| Publishes often (per doubling above 4 per month) | −12 |
| Per-package monorepo tag | −36 |
The size of a version step is judged against the release before it, from the same project and the same line of development, by the leftmost digit that changed. Clients that date their releases keep the month where a minor version would fall, so 26.8.1 to 26.9.0 reads as a minor, and 26.12.0 to 27.1.0 reads as a minor across the new year, not the major the bare number suggests.
Two of the bonuses shrink as a project spends them freely, because a mark means something only while it stays rare. The version bonus weighs against how often that project takes a step of the same size. One execution client has run to major 27 in 53 releases and moves the first digit at 47 of them, so its major is worth 11 hours, while another has moved the first digit once in its life and earns 46. The urgency bonus thins the same way against how freely a project marks its releases at all. Across 11,165 releases one client called 96 per cent of them urgent and another 11, and past the halfway mark the word earns nothing, because by then it describes the project’s template and not the release in front of it. We read a project with a short record mostly against the register as a whole, where about one release in nine carries a mark, so that three marks in six releases count for little until the project’s own releases say more.
A publication that numbers its instalments in the title and has carried the column past twelve parts loses a day on each. The number drops out of the title and the name left behind identifies the column, so the write-up of every core developers call and a weekly digest at issue 39 sink back while a two- or nine-part essay holds its place. The penalty only moves a part down the order and never drops it from the stream.
The strength bars run to three, and the third opens at the figure of a security advisory, so a reader may take three bars as that serious. They appear beside releases only. A release declares its weight twice, in the version it moves and in the language of its notes, and the ranking reads both, while an article declares neither, and the 455 articles from network-critical projects split ten scores between them, so a bar on an article would have measured its publisher while passing for a verdict on the piece. Of 12,856 releases, 60 show three bars, and 59 of those quote urgency wording from their own notes.
A patch whose notes offer no reason to look loses a day and a quarter, which it needs because the floor under any network-critical release once climbed above the ceiling over any article. A patch that does carry urgency wording keeps its full standing, as a security fix ships as a patch more often than not.
| Mark | The words that set it |
|---|---|
| Security | security release, security fix, security advisory, security patch, a CVE number, or any word beginning “vulnerabilit” |
| High priority | high-urgency, high-priority, critical-urgency, critical-priority, and critical followed by update, upgrade, release, patch, stability patch, issue, bug, fix or bugfix, except where “not” stands before it, and an upgrade or update asked for as soon as possible, ASAP or immediately |
| Recommended | recommended release, recommended upgrade, recommended for all, we recommend, required for, mandatory upgrade, mandatory release, must upgrade |
| Breaking | breaking change, BREAKING, incompatible, action required |
Several client teams grade their own releases high, medium or low. High sets the mark, medium sets none and earns twelve hours while sparing a patch the penalty for saying nothing, and low leaves the entry as it stands. A grade the team gives for a test network counts the same as one for mainnet. Severity stays out of the reading, since in these notes it grades a bug or a CVE and the CVE number already sets Security.
The first mark to appear settles the entry, so notes that name both a vulnerability and a breaking change come out marked Security. The wording that set the mark travels with the entry, and the internal reporting displays it, so every mark leads back to the sentence behind it.
The words are read only from the release notes, and only within their first 2000 characters, with bold and code formatting taken out, so a **critical** update reads as a critical update. A team that edits its notes after publishing gets the edit read, since every pass reads the latest releases again. They count on releases and pass over articles, where the same word belongs to the subject and not to a warning: a firm that audits contracts writes vulnerability into nearly everything, which once dressed a write-up of a capture-the-flag contest in the red of a security advisory. The patterns appear here so a reader can hold a mark against them. An entry marked Security holds its standing whatever its version number reads.
No more than one entry from a project reaches the promoted section on a given day.
A few sources belong under “Also collected” whatever they score. A company blog that mostly documents its own product earns a place in the record and repays a search, and it fills its topic in the stream, yet one wallet maker on its own held 53 per cent of the Wallets group and eleven of its first twenty-five rows, at the 2-hour scores the rules had already handed it against the 26 and 28 of the houses beside it. A chronological stream orders entries and does not drop them, so this call rests with the source, set by hand and written into the register. A release from one of these sources that carries a security notice rises all the same.
What reaches the top section
Weight decides the order among the entries that qualify, and qualifying turns on the entry itself. A release reaches the promoted section when something in it makes the case: a security note, a major version, coverage across several publications, or a companion post from the project. An article qualifies as a matter of course, because a person sat down to write it, where a release can leave a build pipeline with no hand on it.
The section exists because the head of the page once went to whichever project carried the biggest name. A consensus client shipping its routine monthly minor scored 101 hours, 90 of them earned by being a client that publishes seldom and 11 by the release itself, and at roughly six such releases a month one of them led the page every fifth day or so on the author’s name alone. Everything that misses the bar waits in the stream.
When several outlets report the same thing
A release states its urgency in its own notes. An article cannot, since no blog post will call itself important, so agreement between publications stands in for it: when several cover one thing within three days, that agreement is the story, and it appears once with a link to each rather than as three rows running together. A second independent source adds half a day of head start, a fourth about a full day.
Grouping turns on rare pairs of words in the headlines. “Clarity act” shows up in a handful of pieces and serves as evidence, while “act” by itself falls in every second bill and means little. Two pieces from one publication never group, because a house writing twice on its own subject runs a series and corroborates no one. Hovering a group shows the words it rests on.
The label reads “also reported”, which is the most the measurement will bear. Across 474 articles it turned up eight groups, six of them one event and two the same subject in separate pieces, so “the same story” would overstate a quarter of them.
Security advisories and exploited vulnerabilities
Three kinds of source file entries under the Security mark. GitHub publishes security advisories for the repositories of the projects on the register, and those of the network-critical and high-weight projects arrive here. CISA keeps the catalog of known exploited vulnerabilities, which we read for the products on the infrastructure list. Mozilla files every incident of a publicly trusted certificate authority in Bugzilla, and the ones that name a compromise of the authority itself arrive here. Each source is read once an hour, which keeps the load on three public services small, while the collector keeps its five-minute cycle for releases.
The mark stands because the publisher filed the entry as a vulnerability or a trust incident, which is the source stating it, and the excerpt is the publisher’s own text word for word. The caption under the excerpt names that publisher, GitHub security advisory, CISA KEV catalog or Mozilla CA Program, because an entry about the Linux kernel stands under the project name “Linux kernel” while CISA wrote the sentence. For an entry from CISA the required action and the ransomware field print as labelled fields taken from the record, the ransomware field only where CISA says use is known. An advisory takes no version step, no patch penalty, no cadence penalty and no damping for how freely a project marks, since those measure how a project handles its releases.
Identifiers
The GHSA id keys every GitHub advisory, since most never receive a CVE id. Measured on 31 October 2026, Besu has 38 published advisories, 3 of them with a CVE id and 5 with a CVSS vector, Go Ethereum has 17, Lighthouse 8, all filed on 26 October, and Lodestar 3. A CVE id that GitHub assigns later is added to the row, and one CVE stands once per project, whichever source names it first. With 33 of Besu’s advisories carrying no vector, the severity the maintainers file an advisory under decides for most of them: critical and high stand in the stream, medium and low under “Also collected”, and none of them without a vector reaches the top section.
Where an advisory lands
CISA’s decision table for the remediation timelines of BOD 26-04 settles where an entry lands, in place of a threshold on the CVSS score. CVSS rates how bad a flaw is in isolation, and the table adds three facts about it: whether it is exploited, whether the internet can reach the affected part, and whether the attack can be automated. The sixteen rows below are copied from the file cisa_bod_26_04_1_0_0.csv, version 1.0.0, in the CERTCC/SSVC repository, and the four inputs read as follows.
- In KEV reads CISA’s catalog, which we mirror in full, so an advisory for a client is checked against it as well.
- Publicly exposed reads the CVSS attack vector. For a component of the infrastructure list it needs the register’s word “internet” and a network attack vector together: the TCP stack of the Linux kernel faces the network, and a local privilege escalation in the same kernel does not. The clients face the peer network, so for them the attack vector alone counts.
- Automatable and technical impact come from CISA’s own SSVC assessment on the CVE record where CISA has made one. Otherwise they come from the CVSS vector, version 3.0, 3.1 or 4.0, taken from the CNA first, then from CISA, then from any other container: an attack is automatable when the vector is network, the complexity low, no privileges are needed and no user takes part, and the impact is total when confidentiality and integrity are both high. Two choices lean towards fewer entries in the top section. Automatable asks for no privileges, which SSVC would not strictly need, and total impact asks for confidentiality and integrity together, where SSVC would accept confidentiality alone. An entry with neither an assessment nor a vector reads as not automatable with partial impact.
| Row | In KEV | Publicly exposed | Automatable | Technical impact | Outcome |
|---|---|---|---|---|---|
| 0 | no | no | no | partial | Fix on system upgrade |
| 1 | yes | no | no | partial | 14 days |
| 2 | no | yes | no | partial | 60 days |
| 3 | no | no | yes | partial | 60 days |
| 4 | no | no | no | total | Fix on system upgrade |
| 5 | yes | yes | no | partial | 14 days |
| 6 | yes | no | yes | partial | 14 days |
| 7 | no | yes | yes | partial | 14 days |
| 8 | yes | no | no | total | 14 days |
| 9 | no | yes | no | total | 14 days |
| 10 | no | no | yes | total | 60 days |
| 11 | yes | yes | yes | partial | 3 days |
| 12 | yes | yes | no | total | 3 days and forensic investigation |
| 13 | yes | no | yes | total | 3 days and forensic investigation |
| 14 | no | yes | yes | total | 3 days |
| 15 | yes | yes | yes | total | 3 days and forensic investigation |
The outcome decides where the entry shows. All of them carry the Security mark.
| Outcome | Where it shows |
|---|---|
| 3 days, with or without forensic investigation | The stream, and the top section for at most 48 hours while it ranks high enough: the weight of the project plus 96 plus 36 hours |
| 14 days | The stream: the weight of the project plus 96 hours, and never the top section |
| 60 days, or a fix on system upgrade | Under “Also collected”, searchable and out of the stream |
Four kinds of entry never take the step to the top section, and where the table says three days they show as fourteen. The six home-router vendors on the list, because vendors in that class carry dozens of entries on end-of-life models. The management plane, hypervisor consoles, BMCs and the tools that build and configure servers, because those sit where only administrators reach them, although CISA’s table gives an exploited flaw there three days whether or not the system faces the internet. And a flaw from the CVE list that CISA has not seen exploited, because the publishers’ own vectors would have put 591 records on the front page in the twelve months to October 2026, 464 of them in the Linux kernel, where btrfs, single network card drivers and NFS servers are rated as reachable from the internet. Such a flaw stands in the stream from the day it is published and takes the lead on the day it enters the catalog. And a flaw whose technical impact CISA rates as partial, which covers a denial of service such as a firewall that reloads. The table gives such a flaw three days once it is exploited and reachable, while the attacker gains limited control or only interrupts the service.
An entry that does take the step holds the top section for 48 hours at most, counted from its date or from the hour our collector first saw it, whichever comes later. At 138 hours of head start it would otherwise stay above every release for most of a week, where nine in ten promoted releases reach 50. After the 48 hours it stays in the stream under its date. An outcome of 60 days or a fix on the next upgrade is the one case where an entry marked Security lands under “Also collected”, because the table gives those flaws its longest timelines.
The catalog carries neither a vector nor an assessment, so for each entry we keep, the collector fetches the CVE record from the CVE Program and stores it beside the entry. Once a day it looks again at the records of entries younger than 90 days, which lets CISA’s own assessment reach the score when it arrives after the entry, and a CVE the CVE Program rejects hides its row.
The CVE list
A critical flaw is public before CISA sees it exploited, so the collector also reads the CVE list itself, the CVEProject/cvelistV5 repository, through the archive of changed records its releases carry every hour. A record is taken when the vendor and product it names, or the CNA that published it, match a component of the infrastructure list, and when it was published in the last thirty days. CISA’s table then runs on the record’s own CVSS vector, or on CISA’s assessment where the record carries one, and the entry is kept for an outcome of 3 days: reachable from the internet, automatable and with total impact, the kind of flaw a worm is built on. Outcomes of 14 days count only once CISA lists the CVE, and the six home-router vendors come in through the catalog alone. Over the twelve months to 31 October 2026 the list would have added 133 entries that way, about two and a half a week. The headline is the title the CNA gave the record, or the first sentence of its English description, and the excerpt is that description word for word, under the caption “CVE record”. Such an entry stands in the stream, shown with fourteen days, until CISA lists the CVE. On that day the row moves to the catalog date and can take the lead.
The Linux kernel team is its own CNA and files a record for nearly every fix. In the twelve months to 31 October 2026 it published 9,360 records, and 897 of them carried a network attack vector together with an automatable assessment, with net, nfsd, netfilter, ksmbd, smb, libceph, sctp, ntfs, scsi, ipv6, sunrpc and btrfs at the top of the prefixes. A node runs the IP stack, the transport protocols, connection tracking and IPsec by default, Docker’s default network runs through the bridge, and the kernel loads the others only where an operator mounts an NFS share or a Ceph volume. A kernel record is therefore kept when its title opens with ipv4, ipv6, tcp, udp, icmp, inet, netfilter, nf_ or nft_, xfrm, esp, skbuff, gro, gso, neigh, bridge, or net: with no second prefix or with core, skbuff, gro, gso, ipv4, ipv6, tcp, udp, icmp, inet, neigh, xfrm, esp or bridge. Over those twelve months the rule and the gates together would have kept 59 kernel records outside the catalog. A kernel CVE that CISA lists is kept whatever its prefix.
The infrastructure list
The list holds the software and hardware that stands on a node host or on the path to it: operating systems, hypervisors, out-of-band management, VPN gateways, firewalls and routers, reverse proxies and DNS, monitoring, backup, remote access, datastores, secrets and deployment tooling. Every category keeps its market alternatives side by side, so a vendor stands on the list for the product it makes in a category, however often CISA names it. Software whose reach ends at a workstation or in somebody else’s data centre has no place on it: desktop operating systems and browsers, phones, office and enterprise application suites, web publishing stacks, mail servers and gateways, home storage appliances, cameras and industrial controllers, desktop virtualisation, Java application servers, artifact registries, developer toolchain packages, hosting control panels, service desk and file transfer products, AI tooling, cloud provider control planes and branch-office WAN orchestration. Validator software belongs to the client feeds. The register holds the names below, and each carries the spellings CISA and the CVE list use for it.
- Operating System. Linux kernel, Ubuntu, Debian, Red Hat Enterprise Linux and rebuilds, SUSE Linux Enterprise, openSUSE, OpenSSH, sudo, GNU C Library, GNU Bash, systemd, OpenSSL, chrony, ntpd, systemd-timesyncd
- Containers & Orchestration. Docker Engine (Moby), containerd, runc, Podman, Kubernetes, k3s, RKE2, Rancher, Red Hat OpenShift, Helm, Argo CD, Flux, etcd
- Virtualisation. VMware ESXi, VMware Tools, VMware vCenter Server, KVM, QEMU, libvirt, Proxmox VE, Xen Project, Microsoft Hyper-V
- Out-of-Band Management. Dell iDRAC, HPE iLO, Supermicro BMC, AMI MegaRAC, Intel AMT / vPro, Lenovo XClarity Controller
- Language Runtime. Java SE / OpenJDK, Node.js, Go
- Deployment Tooling. Python, Ansible, Terraform, OpenTofu, Salt, Puppet, Chef, Git, Jenkins, GitLab CE/EE, GitHub Actions and runner, JetBrains TeamCity
- Secrets & Keys. HashiCorp Vault, OpenBao, Thales Luna HSM, Utimaco HSM, Yubico YubiHSM, YubiKey, AWS CloudHSM, AWS KMS
- Networking Software. WireGuard, strongSwan / Libreswan (IPsec), OpenVPN, Tailscale, Headscale, NetBird, ZeroTier, iptables / nftables, ufw, firewalld, fail2ban, CrowdSec, nginx, Apache HTTP Server, HAProxy, Traefik, Caddy, Envoy, HTTP/2 implementations, ISC BIND, Unbound, CoreDNS, dnsmasq, PowerDNS, Web PKI trust stores
- Network Hardware. Cisco network devices, Fortinet security appliances, Palo Alto Networks PAN-OS, Juniper Junos OS, MikroTik RouterOS, Ubiquiti network devices, Check Point gateways, SonicWall, Sophos Firewall, WatchGuard Firebox, pfSense, OPNsense, Citrix NetScaler, Ivanti Connect Secure, F5 BIG-IP, Progress Kemp LoadMaster, Arista EOS, DrayTek Vigor, Zyxel network devices, NETGEAR network devices, TP-Link routers, D-Link routers, ASUS routers
- Monitoring. Prometheus, Alertmanager, node_exporter, Grafana, Grafana Loki, Zabbix, Elastic Stack, Nagios XI, Nagios Core, Checkmk, LibreNMS, Paessler PRTG, SolarWinds Orion Platform, Progress WhatsUp Gold, Netdata, Uptime Kuma, InfluxDB, Telegraf, VictoriaMetrics, Graylog, Splunk Enterprise, Wazuh
- Datastores. PostgreSQL, Redis, Valkey, MySQL, MariaDB, MongoDB Server, ClickHouse, MinIO, RabbitMQ, Apache Kafka
- Backup. Veeam Backup & Replication, Veritas backup, Acronis Cyber Protect, Commvault, NAKIVO Backup & Replication, Arcserve UDP, restic, BorgBackup
- Remote Access. TeamViewer, AnyDesk, RustDesk, ConnectWise ScreenConnect, SimpleHelp, BeyondTrust remote access, N-able N-central, Kaseya VSA, Webmin, Cockpit, Apache Guacamole, Teleport, MeshCentral
Incidents at certificate authorities
A compromised certificate authority gets no CVE. Mozilla’s CA Program files every incident of a publicly trusted authority in Bugzilla, and the eMudhra key compromise stood there as bug 2083449 on 18 October 2026, three and a half days before the first client release named it. The collector keeps a bug when its summary names a key compromise of an authority or a compromise of a root, intermediate, subordinate or issuing CA, or unauthorized access to the systems of an authority, and, in the component “CA Certificate Root Program”, a distrust or the removal of a root. Over the twelve months to 31 October 2026 the product held 537 bugs, almost all of them routine compliance findings such as OCSP encodings, late audits and typos in a certification practice statement, and these patterns keep three of them: eMudhra, and the intrusions at DigiCert and TWCA. Mis-issuance and issuance using keys previously reported as compromised concern the keys of subscribers and run to dozens a year, so the patterns pass over them. A compromised key or a distrust takes the outcome of three days and can lead the page, since it concerns every HTTPS client, which includes checkpoint sync, Web3Signer and the connections between a validator client and a beacon node. An intrusion into the systems of an authority says that a breach happened and leaves open whether anything was issued or signed, so it stands in the stream with fourteen days.
Editor’s picks
An editor’s pick wears a marker and moves nothing in the order. It keeps the place the rules give it, with our note alongside. The site runs no paid placement and no advertising, and should either arrive, a label will say so and a slot of its own will hold it, clear of the ranking.
Releases and articles
The two switches answer two audiences. A reader running nodes or writing contracts comes for the versions and skims the prose, while a reader following the ecosystem from the business side comes for the writing and would otherwise scroll past eleven thousand version numbers to find it. Topic and form run on separate axes, which is why the switch sits apart from the topic chips: Scaling with articles only is a fair view, and one row of chips could never carry it. Everything shows by default, because the combined overview is the whole point.
Release candidates
A release candidate holds the same information as the release behind it, often by several days, and it takes a section of its own below the stream. Nethermind 2.0.0-rc2 ran to 623 changes and a reworked archive layout and stood as the most informative entry of its week, back when it fell in with the automatic nightly builds. An entry lands here when the project flags the release as a prerelease and the version names it a candidate, a beta, an alpha or a preview. The version alone would gather the wrong ones, as Noir names every release v1.0.0-beta.N and flags none of them; the flag alone would flood the section with automatic builds, as Xatu flagged 91 releases in the year to 16 September 2026 and named none of them. Nightly builds, snapshots and canaries keep out.
Links open in a new tab
Every outbound link opens a fresh tab, and it tells a screen reader as much. A reader who came back to this page would otherwise lose their filter, their scroll position and a full server render across eleven thousand entries. The referrer rides along on purpose, so the sites linked from here can see that Shippeth sent the reader.
Counting opens and shares
Links pass through /go/<id>, which notes that an entry was opened and then forwards to the source, and the share button copies that same link with a mark that keeps the opens a share brings apart from the clicks made here. These counts stay out of the ranking and will remain out of it, because a ranking that rewards clicks rewards whatever is most clickable, and on a page of release notes that is the wrong thing to reward. They also appear nowhere on the site: nothing authenticates a click, and a number printed beside an entry is one that any visitor with a loop can run up. We read them in the internal reporting and leave it there.
Our own projects
Stereum Services FlexCo runs Shippeth and also builds Stereum and StereumLabs, and its founder runs RockLogic GmbH, whose blog appears in the register with the rest. Entries from all four wear a Founder affiliation marker in every view, compact rows included, and not one of them gains a place in the order for it.
What we get wrong
The rules are blunt, and a patch can outweigh a minor version without the ranking ever knowing it. Against that, nothing is hidden. The stream runs in the order things appeared, everything the rules push below the line waits under “Also collected” within reach of the search box and the crawlers, and every entry names its project and its publication and links back to the source.