Attestation Station’s core mechanism is a minimal onchain claims registry keyed by (creator, about, key) -> bytes.
The protocol is intentionally sparse. In the reviewed materials, the contract does not add schema registration, resolver execution, issuer admission, or rich lifecycle management.
The most important design choice is social rather than cryptographic: the system leaves meaning to conventions, apps, and indexers instead of enforcing one canonical attestation model onchain.
Because anyone can write attestations and batch them, trust has to move upward into key naming, community norms, app-level filtering, and issuer reputation.
The reviewed source also implies a useful comparison point with richer attestation systems: if EAS, Sign, Verax, or Attest Protocol look complex, Attestation Station helps show exactly which extra layers they are adding.
Specific source signals worth retaining
attestation-station.md: best source for the project’s own framing — “as simple as possible” — plus the canonical four-field explanation and the existence of SDK / CLI / indexer tooling.
AttestationStation.sol: best source for the actual primitive. The mapping layout, AttestationCreated event, and public attest functions make the design legible in one screen.
optimism-starter README: useful evidence that Optimism positioned Attestation Station as something builders were expected to hack on directly rather than as a sealed product.
Why this entry belongs in the corpus
It strengthens the attestation cluster by adding a stripped-down baseline beneath richer schema-and-policy systems.
It makes later comparison work more precise because it separates simple storage of claims from schema governance, resolver policy, issuer discovery, revocation semantics, and credential portability.
The durable insight is that many attestation systems are not defined by “attesting” alone, but by which optional layers they add above a minimal shared registry.