Developer FAQ¶

Sign Protocol is an evidence and attestation layer for producing and verifying structured claims. A claim can be a statement, an authorization, an eligibility result, an approval, a verification outcome, or any other fact that must be inspectable later.

It standardizes how claims are structured, signed, stored, queried, and referenced, so one verification can be reused across applications.

See the Sign Protocol Developer Docs and, for its role in national systems, Sign Protocol: Attestation Architecture.

No. Sign Protocol is a protocol layer that defines how attestations and related proofs are produced and verified. It can use underlying chains and storage layers for anchoring, settlement, and tamper-evidence, so application workflows are not tied to a single ledger.

An attestation is a signed, structured statement about a subject, usually bound to a schema that defines its fields and semantics. It is meaningful only in its verification context: who signed it, what authority they had, what schema it conforms to, and how revocation and updates are handled.

See Attestations.

An attestation is the signed statement. Evidence is the supporting material that makes the statement credible and inspectable, such as references to documents, cryptographic proofs, verification transcripts, or audit artifacts.

Evidence is an input to verification and dispute resolution, and its handling is tied to privacy and access control. See How Evidence Works in the whitepaper.

A schema defines the structure and semantics of an attestation. It specifies what fields exist, how they are encoded, and how verifiers should interpret them.

Schemas make attestations machine-verifiable and comparable across applications and organizations.

See Schemas.

The Schema Registry is where schemas used by Sign Protocol are registered and discovered. It lets schemas be reused and interpreted consistently, and gives verifiers a stable reference.

See Schemas.

Both. The choice depends on privacy, cost, latency, and audit requirements. Common approaches: - On-chain anchoring for integrity and global verifiability - Off-chain storage for sensitive or large payloads, with cryptographic binding to an on-chain commitment or identifier

See Data Storage and the sections on writing and querying data.

Verification includes: - Schema verification: confirm the attestation conforms to the referenced schema - Signature verification: confirm the signer and the signing domain - Authority verification: confirm the signer was authorized to issue that type of statement in the relevant governance model - Status verification: confirm revocation, expiration, supersession, or dispute status - Evidence verification: confirm referenced proofs or artifacts meet the verifier's acceptance policy

For implementation, see: - Querying Data - Writing Data

Treat attestations as append-only records. Instead of changing history, you can: - Revoke attestations - Issue a superseding attestation - Attach dispute or correction attestations under defined rules

Supported networks change over time. For the current list, see Supported Networks.

EAS is used mainly in EVM environments and is shaped by the EVM execution and data model.

Sign Protocol is an attestation and evidence layer that can be deployed across multiple environments and supports different storage, privacy, and verification models. In practice, the two differ in interoperability, data-location options, and integration with non-EVM systems.

Yes. Typical contributions: - Documentation fixes and clarifications - Bug reports and reproducible test cases - Pull requests to relevant repositories, where applicable

Do not disclose vulnerabilities in public issue trackers. Use the project's security reporting process. If the repository lists no security contact, use the organization contact on the documentation site or in the repository metadata and ask for secure disclosure instructions.

• Documentation issues: open an issue or pull request in the relevant repository
• Developer support: use the project's community or developer channels
• Product and deployment discussions: use the contact paths for institutional engagements

Include environment details, expected and actual behavior, and minimal reproduction steps.