What is Seed Protocol?

Publishing content on the internet has revealed itself to be a Faustian bargain. First the good: It's easy to do, the content is made available instantly, and anyone with an internet connection can access it. This is what has drawn the world to the internet in the first place.

But the issue we're seeing after decades of internet publishing is that content creators implicitly expected platforms to be open and permanent. That's the UX that is presented. No one is warned about platform risk or educated on personal digital archives. Companies and apps either willfully or unconsciously downplay their impermanence and encourage all users to put all their content on their platform. Even when the people behind the platform know the chances of them being around in ten years is historically unlikely.

The CMS, the social network, the newsletter tool — they all sit between the creator and their audience, and they can all disappear. When they do, the content goes with them, or the URLs break, or the export is a CSV that nobody can do anything useful with. Even when the company survives, the relationship is fundamentally one of tenancy: the creator is a guest on someone else's server, subject to someone else's terms.

Seed Protocol is a way to publish content that doesn't depend on the continued existence of any org, developer, or company. If everyone who works on Seed Protocol walked away tomorrow, the content already published with it would remain readable, editable by its owners, and discoverable by anyone who wanted to build a new client. Published content lives on public networks — attestations on Ethereum Attestation Service (EAS) and files on Arweave — rather than in any one app's database, and it stays under the control of the account that published it.

Nuts and bolts

Seed Protocol is three things working together:

• A set of TypeScript packages that give you a familiar data layer — schemas, models, items, live queries, React hooks — backed by a local SQLite database, plus the tools to publish, read, and syndicate that data
• A set of conventions on EAS for representing content as signed attestations, so anyone can read that content, and anyone can publish their own, without asking permission
• An Arweave integration for content that doesn't fit on-chain, like images, files, and long-form text

You write code that looks like any other modern app. Underneath, your data is stored locally for speed, attested by the user's own account for ownership, and copied to public networks for permanence. To see how the packages fit your stack, see The Seed toolkit.

How it works in practice

A creator using a Seed-based app writes a post. The post is stored locally first, so the app feels instant. When the user is ready to publish, the app uploads the content itself to Arweave, then records attestations on EAS — made by the user's account — saying that this account published this content, with pointers to the Arweave uploads. Both records are public and queryable by anyone.

Another app — built by someone else, on the other side of the world, with no relationship to the first — can query an EAS indexer for items published under a schema named post, and surface the posts published with that schema. The original creator can publish edits or revoke their posts because their account made the attestations; nobody else's account can.

In the same way that HTTP lets any browser read any website, content that follows Seed Protocol's conventions can be read by any Seed-compatible client. The protocol is the contract; the apps are interchangeable.

The result is a public stream of content, owned by the people who created it, queryable by anyone. A search for post surfaces posts. A search for recipe surfaces recipes. Anyone can build a reader, a feed, an aggregator, or a filtered view — including serving their own RSS feed at a URL like yourdomain.com/posts/rss with @seedprotocol/feed. The underlying data is as permissionless as EAS itself.

Why these choices

Three design commitments shape everything else:

Attestations as the primitive. Ethereum Attestation Service provides a generic, permissionless way to record signed claims on-chain. Any piece of structured data can be an attestation — which means an attestation can be a row in a public database that anyone can read, and that only its attester can revoke or supersede.

Ethereum, for now. Ethereum is the network most likely to still be running in fifty years, which matters when the promise is permanence. The protocol is being designed to extend to other chains for resilience, but Ethereum is where the canonical record lives. Today Seed Protocol is testnet only: the contracts run on OP Sepolia, an Optimism testnet, until the mainnet launch.

Arweave for blobs. Storing images and large files on-chain is prohibitively expensive. Arweave is purpose-built for permanent storage, paid for once, up front, and any Arweave gateway can serve the data, not just Seed's.

What you can build with it

Anything that today looks like a CMS, a social client, a notes app, a publishing tool, or a personal knowledge base. Seed Protocol is most useful when the content has long-term value to its creator and you want the option of multiple clients reading the same data — a blog and an RSS reader and a search tool, all pointing at the same posts.

It's less useful for transient or high-throughput data (chat messages, live cursors, telemetry) where permanence is a cost rather than a feature.

Where to go next

• If you want to try it: Quickstart — a working app in about ten minutes
• If you're evaluating it: How Seed Protocol works — the architecture, in depth
• If you want to see how it fits your stack: The Seed toolkit — every package, by layer
• If you're comparing it to alternatives: Why Seed Protocol — when to use it instead of Supabase, Payload, or Strapi