Roadmap

Seed Protocol runs on OP Sepolia today, a testnet. The packages are pre-1.0, and releases may still change APIs; the Changelog and Upgrading record every breaking change. Items in progress have been started and have steps still open; planned items are decided and not started; items under Exploring are ideas or open questions that may change shape or not happen. Except where an item says it's confirmed, the items are plans, not commitments, and their order isn't a schedule.

In progress

Finishing the OP Sepolia contracts rollout

The current contracts went live on 2026-10-30, and the routing change and on-chain checks are done. What's left is on Seed's side: moving its own apps to 0.8.0 and the current executor, confirming publishes on the test accounts, with the executor installed and session keys granted again, and removing the old deployment records from the contracts repository. Deployments has the addresses.

Planned

Mainnet deployment

Mainnet is not deployed, and the deploy plan for the testnet rollout leaves it out of scope. The compiler upgrade it required is done: the contracts build with solc 0.8.38 for EVM target cancun, and OP Sepolia runs that build. The extensions take the EAS address, so their mainnet addresses will differ from the OP Sepolia ones.

Before mainnet, the factory's admin roles, EXTENSION_ROLE and DEFAULT_ADMIN_ROLE, move from a single Seed-operated key to a multisig (confirmed). These roles decide which code runs in every ManagedAccount; see Trusting the factory admin.

Schemas that choose their seeds

Model types are global on-chain: every app's Post publishes under the same EAS schema, which is what lets apps share data. Locally, though, an app should only see the seeds its schema describes. The accepted design:

• Properties get a match setting ('any', 'required', 'requiredTogether', 'ignore') that decides whether a seed belongs to a model, and models get a matchMode ('loose' or 'strict') and a syncScope ('match', 'all' or 'referenced').
• EAS sync stores only seeds that match a local schema, plus the seeds they relate to.
• The client gets an active schema (from a call, a SeedProvider prop, config.activeSchema, config.schema or a root seedSchema.json), and item lists default to it.

This will be a breaking change for apps with an active schema, which includes every app that sets config.schema: lists will shrink to the seeds linked to that schema, and sync will skip seeds that have none of a model's properties. It's planned for a minor release with migration notes.

Contract testing and analysis

Follow-ups recorded for the contracts: an invariant test that the EAS attester is always the account, and the Slither and Aderyn static analyzers in CI. Fuzz tests for multiPublish references are done.

Open-sourcing Seed's gateway

The Seed Protocol team runs its own private AR.io gateway so that uploads are immediate and sponsored. Its code is planned to be open-sourced.

Exploring

Finer-grained delegate permissions

Session keys today can publish anything their account can, and can't revoke. Three ideas are recorded, none built:

• a per-account allowlist of the schemas multiPublish may attest, which limits what a delegate can publish;
• separate permissions per delegate (schemas, expiry), with each app calling from its own address against an owner-managed registry;
• letting a delegate revoke only what it published, which needs the per-delegate model and is to be revisited if users ask for automated revocation.

Strict matching over a time window

With schema-scoped seeds, strict mode looks only at a seed's latest version. Choosing "latest" within a time range is deferred to a later decision.

A shared design system for exported components

The components in @seedprotocol/react, @seedprotocol/mapping and @seedprotocol/publish style themselves differently: OPFSFilesManager and FieldMapper use injected stylesheets with CSS variables, while PublishModeButtons, ConnectButton and SeedClientGate use hard-coded styles. A proposal would give all of them one set of --seed-* tokens and shared buttons, dialogs and loading states.

Sealed Versions

A Version can be amended today: a patch publish attests more properties onto it, so a read that must not change pins a time with asOf as well. A proposal would let an owner seal a Version with one more attestation that lists the property attestations the Version holds. Readers would ignore anything attested onto a sealed Version later, and a change would go to a new Version instead. Revoking a sealed value would still remove it by default, so an owner can always withdraw what they published. Nothing is built, and the work waits for an app that needs it.

FieldMapper

@seedprotocol/mapping can't yet map several sources into one property, such as two author fields or a title built from a template.

Related

• Changelog
• Deployments: what has shipped, with dates
• Security and session keys