* feat: Add Enclave Usage Examples * feat(es/ucan): Add comprehensive integration tests - Create integration.test.ts with full UCAN token lifecycle testing - Cover end-to-end token creation, parsing, and validation - Test capability attenuation and delegation chains - Validate multi-algorithm support and timestamp scenarios - Implement error recovery and performance test scenarios 🤖 Generated with Claude Code Co-Authored-By: Claude <noreply@anthropic.com> * No commit suggestions generated * No commit suggestions generated * chore: Remove migrated components and add migration documentation Removed all code and references for components that have been moved to separate repositories: **Moved to sonr-io/hway:** - bridge/ - HTTP service with OAuth2/OIDC/WebAuthn handlers - cmd/hway/ - Highway service binary - internal/migrations/ - PostgreSQL schema migrations **Moved to sonr-io/motr:** - cmd/motr/ - Motor worker service (WASM vault operations) - cmd/vault/ - Vault CLI tool - crypto/ - Comprehensive cryptographic library - packages/ - TypeScript SDK packages (es, sdk, ui, com, pkl) - web/auth/ - Authentication web application - web/dash/ - Dashboard web application **Updated Configuration:** - Makefile: Removed build/test/release targets for moved components - CLAUDE.md: Simplified to focus on core blockchain components - devbox.json: Removed scripts for moved services - docker-compose.yml: Removed hway, postgres, redis, auth, dash services - .github/scopes.yml: Removed CI scopes for migrated components - .goreleaser.yml: Updated release configuration **Added Migration Documentation:** - MIGRATE_HWAY.md: Comprehensive Highway service architecture and migration guide - MIGRATE_MOTR.md: Comprehensive Motor/Worker/Vault architecture and migration guide These migration documents provide complete context for setting up the new repositories including architecture diagrams, component breakdowns, API documentation, and migration checklists. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> * No commit suggestions generated * chore: Remove contracts references and documentation Removed all references to the contracts directory that was migrated to a separate repository. **Changes:** - .gitignore: Removed contract-specific ignore patterns for DAO and wSNR contracts - .gitignore: Removed hway and motr binary references (already migrated) - .rgignore: Removed contracts, chains, and crypto directory references - docs/reference/contracts/: Removed DAO.mdx and wSNR.mdx documentation files This completes the cleanup of migrated components from the repository. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> * docs: add crypto library migration documentation Added comprehensive migration documentation for the crypto library that was moved to sonr-io/crypto repository. This documentation provides complete context for understanding the cryptographic primitives and protocols used throughout the Sonr ecosystem. ## Key Documentation Added ### MIGRATE_CRYPTO.md Complete documentation of the crypto library covering: **Core Cryptographic Primitives** - Elliptic curve implementations (Ed25519, Secp256k1, P-256, BLS12-381, Pallas/Vesta) - Native curve arithmetic with optimized field operations - Pairing-friendly curves for BLS signatures **Multi-Party Computation (MPC)** - MPC enclave for vault key generation and management - Threshold cryptography (TECDSA, TED25519 with FROST protocol) - Distributed Key Generation (DKG) via Gennaro and FROST protocols - Secret sharing schemes (Shamir, Feldman VSS, Pedersen VSS) **Digital Signature Schemes** - BLS signatures with aggregation support - BBS+ signatures for selective disclosure - Schnorr signatures (standard and Mina/NEM variants) - ECDSA with deterministic nonce generation **Zero-Knowledge Proofs** - Bulletproofs for range proofs - Inner Product Arguments (IPA) - Batch verification support **Advanced Cryptographic Protocols** - Cryptographic accumulators for set membership proofs - Paillier homomorphic encryption - Oblivious Transfer (OT) protocols - Verifiable Random Functions (VRF) **Key Management & Identity** - DID key management with multi-chain support - Multi-algorithm public key handling - Wallet address derivation (Bitcoin, Ethereum, Cosmos, Solana, etc.) **UCAN Integration** - User-Controlled Authorization Networks - Capability delegation and attenuation - JWT-based capability tokens - MPC-enabled UCAN signing **Security Utilities** - AEAD encryption (AES-GCM, AES-SIV) - Argon2 key derivation - ECIES encryption - Secure memory handling ### MIGRATE_MOTR.md Updates Updated Motor migration documentation to clarify that the crypto library is now a separate external dependency at github.com/sonr-io/crypto v1.0.1 ## Repository Context The crypto library has been successfully migrated to its own repository and is published as a Go module. It serves as the foundational cryptographic layer for: - Sonr blockchain (snrd) - DID signatures, vault operations - Highway service (hway) - UCAN token signing, WebAuthn - Motor/Worker (motr) - MPC vault operations, threshold signatures ## Integration Impact All Sonr ecosystem components now depend on the external crypto library: ```go require github.com/sonr-io/crypto v1.0.1 ``` The migration enables independent versioning and maintenance of cryptographic primitives while maintaining security and compatibility across the ecosystem. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> * No commit suggestions generated * No commit suggestions generated * No commit suggestions generated --------- Co-authored-by: Claude <noreply@anthropic.com>
x/svc
The Service (SVC) module manages the registration and operation of decentralized services within the Sonr ecosystem. It provides a comprehensive framework for services to register with verified domains, define their permission requirements, and integrate with the broader Sonr authorization system through UCAN capabilities.
Overview
The SVC module provides:
- Domain Verification: DNS-based domain ownership verification
- Service Registration: Register services with verified domains
- Permission Management: Define and request specific UCAN permissions
- Service Discovery: Query services by owner, domain, or ID
- Capability Integration: Seamless integration with the UCAN module
Core Concepts
Domain Verification
Services must verify ownership of their domain through DNS TXT records before registration. This ensures that only legitimate domain owners can register services.
Service Registration
Once domain ownership is verified, services can be registered with:
- Unique service ID
- Verified domain binding
- Requested permissions (UCAN capabilities)
- Service metadata (name, description)
Permission Model
Services request specific permissions during registration, which are granted as UCAN capabilities. These permissions define what actions the service can perform on behalf of users.
Service Identity
Each service has a unique identity composed of:
- Service ID (chosen identifier)
- Domain (verified TLD)
- Owner (blockchain address)
State
Domain Verification
message DomainVerification {
string domain = 1; // Domain being verified
string owner = 2; // Address initiating verification
string token = 3; // Verification token
VerificationStatus status = 4; // Pending, Verified, Failed
int64 initiated_at = 5; // Timestamp
int64 expires_at = 6; // Token expiration
}
Service
message Service {
string service_id = 1; // Unique service identifier
string domain = 2; // Verified domain
string owner = 3; // Service owner address
string name = 4; // Human-readable name
string description = 5; // Service description
repeated string permissions = 6; // Requested permissions
string ucan_delegation_chain = 7; // UCAN authorization
int64 created_at = 8; // Creation timestamp
int64 updated_at = 9; // Last update timestamp
}
Messages
Domain Verification
MsgInitiateDomainVerification
Initiates domain verification by generating a DNS TXT record token.
message MsgInitiateDomainVerification {
string owner = 1;
string domain = 2;
}
MsgVerifyDomain
Verifies domain ownership by checking DNS TXT records.
message MsgVerifyDomain {
string owner = 1;
string domain = 2;
}
Service Management
MsgRegisterService
Registers a new service with a verified domain.
message MsgRegisterService {
string owner = 1;
string service_id = 2;
string domain = 3;
string name = 4;
string description = 5;
repeated string requested_permissions = 6;
string ucan_delegation_chain = 7; // Optional UCAN authorization
}
Governance
MsgUpdateParams
Updates module parameters (governance only).
message MsgUpdateParams {
string authority = 1;
Params params = 2;
}
Queries
Domain Queries
DomainVerification: Check domain verification status
Service Queries
Service: Get a specific service by IDServicesByOwner: List all services owned by an addressServicesByDomain: List all services for a domain
Module Queries
Params: Get module parameters
CLI Examples
Domain Verification
# Initiate domain verification
snrd tx svc initiate-domain-verification example.com --from alice
# Check verification status
snrd query svc domain-verification example.com
# The system will provide a token like: sonr-verification=abc123xyz
# Add this as a TXT record to your domain's DNS
# Verify domain after DNS propagation
snrd tx svc verify-domain example.com --from alice
Service Registration
# Register a service with basic permissions
snrd tx svc register-service my-app example.com \
dwn:read,dwn:write,identity:read \
--from alice
# Register with UCAN delegation
snrd tx svc register-service vault-service vault.example.com \
vault:access,identity:read \
--ucan-delegation-chain="<jwt-token>" \
--from alice
# Query service
snrd query svc service my-app
# Query services by owner
snrd query svc services-by-owner $(snrd keys show alice -a)
# Query services by domain
snrd query svc services-by-domain example.com
Integration Guide
For Service Developers
-
Domain Setup:
- Register your domain with a DNS provider
- Ensure you have access to manage DNS TXT records
- Choose a unique service ID
-
Verification Process:
# Step 1: Initiate verification snrd tx svc initiate-domain-verification your-domain.com --from your-key # Step 2: Add TXT record to DNS # Record: sonr-verification=<provided-token> # Step 3: Wait for DNS propagation (usually 5-30 minutes) # Step 4: Complete verification snrd tx svc verify-domain your-domain.com --from your-key -
Service Registration:
- Define required permissions carefully
- Use descriptive service names and descriptions
- Consider permission scope and user privacy
-
Permission Planning: Common permission patterns:
dwn:read,dwn:write- Basic data accessidentity:read- Read user identityvault:access- Vault operationscredentials:verify- Verify credentials
For Application Integrators
-
Service Discovery:
# Find services by domain snrd query svc services-by-domain app.example.com # Get service details snrd query svc service service-id -
Permission Verification:
- Check service permissions before integration
- Validate UCAN delegation chains
- Ensure permissions match your requirements
-
User Authorization Flow:
- Service requests permissions from user
- User reviews and approves via wallet
- Service receives UCAN capability
- Service can act on user's behalf
Domain Verification Process
DNS TXT Record Format
sonr-verification=<token>
Verification Requirements
- Domain must be a valid TLD
- DNS TXT record must match the generated token
- Verification expires after 7 days if not completed
- Each domain can only be verified by one owner
Example DNS Configuration
# For domain: app.example.com
# Add TXT record:
Type: TXT
Name: @ (or app if subdomain)
Value: sonr-verification=1234567890abcdef
TTL: 300 (5 minutes)
Security Considerations
- Domain Ownership: Only verified domain owners can register services
- Permission Scope: Services can only request, not grant permissions
- UCAN Validation: All capability chains are validated
- Unique Domains: Each domain can only have one owner
- Service Isolation: Services cannot access data from other services
Module Parameters
verification_timeout: Domain verification timeout (default: 7 days)max_services_per_owner: Maximum services per owner (default: 100)allowed_permissions: List of permissions services can requestservice_registration_fee: Fee for service registration (default: 1000usnr)
Events
The module emits the following events:
domain_verification_initiated: When verification startsdomain,owner,token,expires_at
domain_verified: When domain is successfully verifieddomain,owner,verified_at
service_registered: When a new service is registeredservice_id,domain,owner,permissions
service_updated: When service is updatedservice_id,fields_updated
Building and Testing
Running Tests
# Run unit tests
make -C x/svc test
# Run tests with race detection
make -C x/svc test-race
# Generate coverage report
make -C x/svc test-cover
# Run benchmarks
make -C x/svc benchmark
Best Practices
For Service Developers
- Choose Meaningful IDs: Use descriptive service IDs that reflect your service
- Request Minimal Permissions: Only request what you need
- Document Permissions: Clearly explain why each permission is needed
- Plan for Updates: Design your permission model for future growth
- Monitor Expiration: Keep track of UCAN expiration times
For Users
- Verify Services: Check domain ownership before granting permissions
- Review Permissions: Understand what each permission allows
- Regular Audits: Review granted permissions periodically
- Revoke When Needed: Remove permissions from unused services
Future Enhancements
- Service Categories: Categorization for better discovery
- Reputation System: User ratings and reviews
- Permission Templates: Pre-defined permission sets
- Multi-sig Ownership: Support for team-owned services
- Service Analytics: Usage statistics and monitoring
- Subdomain Support: Hierarchical service structures