Why Seed Protocol?

If you're building something where users create content — posts, profiles, comments, knowledge bases, portfolios — you've probably already evaluated Payload, Strapi, or Supabase. They're excellent tools. They'll get you to production faster than Seed Protocol will, today.

The question these tools don't answer

Headless CMSes and backend-as-a-service platforms solved a real problem: building content infrastructure used to require a team, and now it doesn't. One developer can ship a CMS-backed app in a weekend.

But they all share an architecture. The database lives on someone's server. The schema is defined in someone's admin panel. The content is accessible through someone's API. When users create something with your app, they're creating it inside your account on a service provider's infrastructure. If your project shuts down, the content is stranded. If the service provider raises prices, you pay. If they change their terms, you comply or you migrate everything.

For most software, this is fine. For content with long-term value to its creator — writing, photography, a personal archive, a community's record of itself — it's a worse fit than the industry has admitted.

Seed Protocol is built for the cases where the content matters more than the app that produced it.

What's different

Three properties define the design.

Users own their content cryptographically

Published content is recorded as attestations made by the author's own account on Ethereum Attestation Service (EAS), with files and long-form content stored on Arweave. Not "owned" in a marketing sense — owned in the sense that only the author's account, or a key it has explicitly authorized, can publish edits, and only the account's owner can revoke. If your app disappears, the published content doesn't. If a user wants to take their work to another Seed-compatible app, they can, without an export step, because the published record was never in your app's custody.

The same data is readable by any app

Content published through Seed Protocol uses public EAS schemas on a public network. A post written in your app can be read, indexed, or displayed by any other Seed-compatible app — including ones that don't exist yet. This is the property that makes "no platform risk" actually true: a creator's posts can outlive your app because someone else can build a reader for them.

It feels like building any other modern app

This is the part that usually doesn't survive contact with decentralization. Most user-owned data stacks ask developers to think about transactions, gas, signatures, and IPFS pins in their UI code. Seed Protocol's SDK gives you reactive React hooks, a local SQLite database, instant local writes, and a schema you define in code. Publishing is a separate step, and the default setup asks a paymaster to cover gas, so users don't need to hold ETH. The blockchain is an implementation detail of persistence, not a UX problem you push onto your users.

None of these properties is interesting alone. Cryptographic ownership without good DX produces tools only crypto-natives use. Good DX without interoperability produces just another walled garden. Interoperability without a sane local model produces something too slow to use. The argument for Seed Protocol is that you can have all three, and that having all three changes what's worth building.

How it compares

Each of these tools is the right choice for some projects.

Supabase is the right choice when you need a relational database, auth, storage, and realtime, and you're comfortable with your users' data living in your Supabase project. The DX is excellent. The tradeoff is that everything depends on Supabase the company and your account inside it.

Payload is the right choice when you want a code-first headless CMS with a rich admin UI, deep customization, and self-hosting. It's especially strong for editorial workflows. The tradeoff is that the content lives in your database, and "user-owned content" isn't a problem it tries to solve.

Strapi is the right choice when you want a more mature, plugin-rich headless CMS with a polished admin experience and a wide ecosystem. Same fundamental tradeoff: it's content infrastructure for your application, not portable content for the users who create it.

Seed Protocol is the right choice when the content has independent value from the app — when you'd want it to keep working if you stopped working on the app, when you'd want users to be able to take it with them, or when you want the option for other apps to read and write the same data.

If you're building a SaaS dashboard, an internal tool, an e-commerce store, or anything where the data is fundamentally yours rather than your users', use one of the others. Seed Protocol isn't trying to replace them for those cases.

What we're honest about

Seed Protocol is early. The API will change before it stabilizes. Some patterns that work today will be deprecated. The version policy is that we'll document breaking changes clearly and provide migration paths, but if you need a frozen API for a production system shipping next month, you should know this going in.

It's also testnet-only today. Seed's contracts are deployed on OP Sepolia, an Optimism testnet, and there's no mainnet deployment yet (Deployments). The chain is configuration in the SDK, and there's a documented process for deploying the contracts to another chain with EAS, but OP Sepolia is the only live deployment. We think Ethereum is the most credibly-permanent network, which is why we're building on it — but if your project needs mainnet permanence or multi-chain support today, Seed Protocol isn't there yet.

And it's not the right tool for high-frequency or transient data. Chat messages, live cursors, telemetry, ephemeral state — these don't benefit from permanence and shouldn't pay for it. Use a regular database for that, and reach for Seed Protocol when the data is meant to last.

Where to go next

• Add Seed to your app, or build a blog from scratch in the tutorial
• How Seed Protocol works: the architecture
• Build a publishing app: a complete app, start to finish