Attest Protocol

• Name: Attest Protocol
• URL: https://docs.attest.so/introduction
• Tags: stellar-ecosystem
• Category: attestation middleware / schema-and-resolver framework / verified-issuer registry / cross-chain trust infrastructure
• Summary: Attest Protocol is attestation middleware. The useful split is schema ownership, issuance policy, and issuer discovery. Resolvers decide admission, authority registration handles reputation, and BLS delegation pushes submission into a relay layer. Real mechanism note, not an anchor.
• What it does:
  • Lets anyone create schemas and issue attestations by default, unless a schema creator attaches a resolver that restricts issuance or revocation
  • Stores attestations onchain and exposes schema registration, attestation creation, and revocation through a core protocol contract
  • Separately offers a verified-authority registration layer with metadata, trust badges, and issuer discovery for organizations that want stronger reputational signaling
  • Supports resolver contracts that can enforce allowlists, collect fees, distribute rewards, or implement custom validation logic before attestations are accepted
  • Uses BLS delegation so attestations can be signed offchain and submitted onchain by a relayer, shifting gas payment and batch-submission possibilities away from the original issuer key
  • Positions itself as multi-chain trust infrastructure, with Stellar active in current docs and Solana / Starknet / other chains presented as expansion paths in the repo materials
• Key claims:
  • The docs frame Attest as reusable proof infrastructure for identity, ownership, permissions, and other trust signals rather than as one application-specific contract set.
  • The main mechanism worth keeping is the authority / resolver split. Creating a schema makes you its authority, but that alone does not decide who may attest; attached resolvers do.
  • The authorities docs add a second trust layer through optional verified-authority registration with metadata and badges. Reputation can therefore centralize in issuer discovery as well as in schema and resolver design.
  • Resolver contracts are the real policy surface: they can gate issuance, charge fees, distribute rewards, and run custom logic before an attestation is accepted.
  • BLS delegation matters because it separates issuer authority from submission and gas payment, pushing part of the operating model into a relay layer.
  • The multi-chain framing matters even if Stellar is the clearest current production branch. The project is selling interoperable trust middleware, not just a chain-local attestation app.
• Whitepaper: No canonical standalone whitepaper or litepaper surfaced in this pass. The strongest primary materials were the official docs pages for introduction, architecture, authorities, and resolvers, plus the official repository README; see ../whitepapers/attest-protocol-primary-sources-2026-05-10.md.
• Sources:
  • https://docs.attest.so/introduction
  • https://docs.attest.so/concepts/how-it-works
  • https://docs.attest.so/concepts/authorities
  • https://docs.attest.so/concepts/resolvers
  • https://github.com/daccred/attest.so
  • https://raw.githubusercontent.com/daccred/attest.so/main/README.md

Internal linkages

• Best upward comparisons for schema-and-attestation rails: ethereum-attestation-service and sign-protocol.

Control surface

• Real control sits in resolver policy, schema ownership, authority-list curation, relay defaults, and which issuers wallets or apps choose to treat as worth trusting.

• The chain is not the whole story here. Discovery, verification UX, and submission middleware can quietly decide which attestations matter in practice.

• Read it as attestation middleware with a few explicit choke points, not as a canonical trust layer.

• Last reviewed: 2026-06-18 UTC