Browse Schemas
Explore the Schema Registry
AttestProtocol hosts a growing registry of ready-to-use schemas covering identity, credentials, ownership, governance, and more. Each schema includes:- Field definitions and data types
- Usage stats and adoption metrics
- Verified authorities that can issue under it
- Compatibility with supported chains
Example Categories
Identity — KYC, proof of humanity, age verification Ownership — wallet holdings, asset claims, NFT proofs Credentials — GitHub contributions, academic degrees, licenses Actions — event attendance, voting participation Custom — DAO-specific or protocol-specific templates Explore the Schema Registry →Using Schemas
Integrate an Existing Schema
To use a schema in your app or workflow: Select a schema ID from the Registry:Creating Schemas
Define a Custom Schema
Need your own structure? Define a custom schema for your application, DAO, or protocol.Schema Builder (Coming Soon)
A visual drag-and-drop tool for creating and testing schemas without writing code is in development.Schema Standards
AttestProtocol Schema Specification (APSS)
All schemas follow APSS, ensuring consistency and interoperability across the protocol. Key Features:- JSON-compatible structure
- Deterministic field ordering
- Type-safe validation
- Chain-agnostic deployment
- Composable with on-chain resolvers
Versioning
Version Control for Schemas
Schemas evolve over time. AttestProtocol supports:- Semantic versioning (e.g., v1.0.3)
- Backward-compatible updates (optional fields)
- Breaking changes require new schema IDs
- Attestations always reference the exact schema version they were issued under
Migration Guides
We provide tooling and best practices for upgrading to newer schema versions while preserving verification paths. View Migration DocsBest Practices
Designing Trustworthy Schemas
A well-designed schema balances specificity, reuse, and security. Do:- Use clear field names and data types
- Include timestamps and expiration where relevant
- Document validation requirements
- Test schema usage across sample data
- Overloading fields with multiple meanings
- Using ambiguous data types (e.g., strings for booleans)
- Omitting important metadata (e.g., issuer, jurisdiction)
Tools for Testing
- Test suite for schema validation
- SDK mocks for issuing sample attestations
- Integration tests for attestation workflows
Community Contributions
Have a reusable schema idea? Submit it to the public registry for community use and feedback. Submit a SchemaSchema Components
Core Properties
Every schema includes these fundamental properties:| Property | Type | Description |
|---|---|---|
name | string | Unique identifier for the schema |
version | string | Schema version for evolution support |
definition | string | Field definitions and types |
revocable | boolean | Whether attestations can be revoked |
description | string | Human-readable schema purpose |
Field Types
Supported data types for schema fields:Field Definition Syntax
Fields are defined using a simple comma-separated format:Creating Schemas
Schemas are created by authorities and define the structure for their attestations:Basic Identity Schema
Professional Credential Schema
Multi-Entity Governance Schema
Schema Registry
Pre-Built Schemas
AttestProtocol provides standard schemas for common use cases: Identity & Compliancekyc-basic-v1: Basic KYC verificationkyc-enhanced-v1: Enhanced due diligenceage-verification-v1: Age threshold verificationproof-of-humanity-v1: Human verification
professional-cert-v1: Professional certificationseducational-degree-v1: Academic credentialsskill-verification-v1: Technical skillswork-experience-v1: Employment history
dao-member-v1: DAO membership statusvoting-eligibility-v1: Governance participationcontribution-score-v1: Contribution trackingreputation-score-v1: Overall reputation
event-attendance-v1: Event participationgaming-achievement-v1: Gaming accomplishmentstournament-result-v1: Competition outcomesnft-ownership-v1: Asset ownership
Using Registry Schemas
Schema Design Best Practices
Keep It Simple
Design schemas with minimal necessary fields:Use Standard Types
Prefer standard data types for interoperability:Plan for Evolution
Include version information and extensibility:Semantic Naming
Use clear, descriptive field names:Schema Validation
Field Requirements
Schemas enforce data structure at creation time:Type Constraints
Each type has specific constraints:| Type | Constraints | Example |
|---|---|---|
bool | true or false only | verified:true |
uint8 | 0 to 255 | score:85 |
string | UTF-8 text, no commas | name:John_Doe |
address | Valid blockchain address | issuer:0x123...abc |
uint64 | Unix timestamp common | timestamp:1704067200 |