Base schemas

Every Seed attestation is made under an EAS schema. Most of those schemas come from your models and properties, and the publish package registers them as it needs them. A few belong to the protocol itself: every publish uses them, whatever the app.

Schema UIDs are the same on every chain

An EAS schema's UID is keccak256(abi.encodePacked(schema, resolver, revocable)). It doesn't depend on the chain or on who registered it. Every schema on this page is registered with no resolver (the zero address) and as revocable, so each one has the same UID on every chain where it's registered. Registering a schema is permissionless, and a schema can't be changed or removed once it's registered.

Revocable matters: the Seed contracts make every attestation revocable, and EAS rejects a revocable attestation under an irrevocable schema. See Security and session keys.

Protocol schemas

These three are listed in schemas/base-schemas.json in the contracts repo. The OP Sepolia status on this page was read on 2026-10-18 from the SchemaRegistry (getSchema) and OP Sepolia's EAS Scan.

• version is the schema of every Version attestation. multiPublish creates one per publish with refUID set to the Seed, and its data is the Version schema's own UID (abi.encode(versionSchemaUid)). The SDK exports the UID as VERSION_SCHEMA_UID.
• schemaName is EAS's schema for naming schemas. The SDK names every schema it registers with an attestation under it (schemaId, name), and finds model schemas by those names.
• storageTransactionId links a property to the Arweave transaction that stores its file. Its refUID is the Version.

OP Sepolia also has a legacy bytes32 storage_transaction_id schema (0xa1a5bee9e88ea4bac8e7a37a65ce735d47e3a9ff3e428308d40be499b4944817, EAS schema #132, no resolver, revocable, unnamed on EAS Scan). It isn't a protocol schema and isn't the one to use. Its 8 attestations, all from February 2024, hold a string encoded under a bytes32 schema, so a reader decodes each value as 0x…0020 instead of a transaction ID. SDKs before 0.7.6 picked a property's schema by name and could attest uploads under it; the SDK now picks by the exact definition, doesn't read a bytes32 value as an Arweave transaction ID, and doesn't recover those 8.

Who registers them

On a new chain, the protocol operator registers them with npx hardhat seed:ensure-schemas --network <name> from the contracts repo, which registers any that are missing and leaves the rest. --check-only only reports. See Deploying to a new chain.

The SDK only checks version and schemaName. ensureEasSchemasForItem and ensureEasSchemasForModels look both up before the first publish on a chain (once per chain, per process), and if either is missing it fails before anything is sent, with Seed base schema "<definition>" (<uid>) not registered on chain <id> (schemas … and … when both are). string storage_transaction_id is different: if it's missing when a publish uploads a file, the publish package registers and names it like any other property schema.

Model and property schemas

A model becomes an EAS schema when an item of it is first published, and a property when it's first published with a value. Before every publish, ensureEasSchemasForItem (from @seedprotocol/publish) checks every schema that publish attests under and then registers the missing ones, each with no resolver, as revocable, followed by a schemaName attestation that names it with its EAS name. Schema naming has the definition and name for each model and property.

The built-in storage models are model schemas too, and they're registered on OP Sepolia:

Registering costs a transaction per schema plus one per name, sent from the publishing wallet. EAS schemas are shared: if another app already registered string title, your app uses the same one. Change a schema after you've shipped explains why names and types are a contract.

Tool schemas registered by the publish package

@seedprotocol/publish writes three kinds of tool attestations, each under its own schema. Each attest… function registers its schema the first time it's used, unless you pass ensureSchema: false, and the ensure…Schema(wallet) functions do it on their own.

getPublishAuthorizationSchemaUid(), getDomainOwnershipSchemaUid() and getPublishedBySchemaUid() compute these UIDs locally. The attestations themselves are covered in Security and session keys, Domain ownership and Tool attestations.

Checking a schema yourself

Read the SchemaRegistry: on OP Stack chains it's the predeploy at 0x4200000000000000000000000000000000000020. An unregistered UID comes back with a zero uid.

import { createPublicClient, http, parseAbi, zeroHash } from 'viem'
import { optimismSepolia } from 'viem/chains'

const registry = '0x4200000000000000000000000000000000000020'
const abi = parseAbi([
  'struct SchemaRecord { bytes32 uid; address resolver; bool revocable; string schema; }',
  'function getSchema(bytes32 uid) view returns (SchemaRecord)',
])

const publicClient = createPublicClient({ chain: optimismSepolia, transport: http() })

export async function isRegistered(uid: `0x${string}`): Promise<boolean> {
  const record = await publicClient.readContract({ address: registry, abi, functionName: 'getSchema', args: [uid] })
  return record.uid !== zeroHash
}

To get a UID from a definition, SchemaRegistry.getSchemaUID(schema, resolver, revocable) from @ethereum-attestation-service/eas-sdk computes it offline.

Related

• Working with EAS: reading and writing Seed attestations directly
• Deploying to a new chain: registering the protocol schemas on a chain
• Define a schema and add to it
• @seedprotocol/eas: schema lookups by name and UID