go/sonr
1
0
Fork 0
mirror of https://github.com/sonr-io/sonr.git synced 2026-08-02 17:31:39 +00:00
Code Issues Packages Projects Releases Wiki Activity

Master (#1262)

Browse Source 
* clear

* feat: Add everything

* fix: Commenht
This commit is contained in:
Prad Nukala
2025-10-03 14:45:52 -04:00
committed by GitHub
parent 43b4a11c06
commit 13e6c3e84d
1935 changed files with 655061 additions and 40058 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/changelog.mdx
+580
View File
@@ -0,0 +1,580 @@
---
title: Version History
sidebarTitle: Changelog
description: All notable changes to the Sonr blockchain
icon: "hourglass"
---
<Update label="2025-09-04" description="v0.13.3" tags={["DevOps", "Infrastructure", "Docker"]}>
Consolidate deployment infrastructure with Docker Compose and enhance build targets (#248)
- Unified backend services configuration (Highway, Redis, Caddy, IPFS, snrd)
- Implemented multi-stage Dockerfile build targets
- Enhanced Makefile with Docker management targets
- Introduced health check and readiness probe system
</Update>
<Update label="2025-09-04" description="v0.13.2" tags={["Authentication", "WebAuthn", "OIDC"]}>
Implement OpenID Connect provider with WebAuthn in bridge handlers (#244)
- Full WebAuthn passwordless authentication integration
- Implemented Self-Issued OpenID Provider (SIOP) v2
- Blockchain-based WebAuthn credential broadcasting
- Supports Authorization Code Flow with PKCE
</Update>
<Update label="2025-09-03" description="v0.13.0" tags={["Cryptography", "Security", "Testing"]}>
Fix cryptographic implementations and enable disabled tests (#243)
- Fixed and re-enabled previously disabled cryptographic tests
- Enhanced security validation for cryptographic modules
- Improved test coverage for core security components
</Update>
---
<Update label="2025-09-03" description="v0.12.11" tags={["WebAuthn", "Authentication"]}>
WebAuthn attestation and verification improvements (#242)
- Enhanced attestation verification logic
- Improved security checks for authentication ceremonies
- Refined credential validation mechanisms
</Update>
<Update label="2025-09-03" description="v0.12.10" tags={["Services", "Module", "Configuration"]}>
Implement Service module capability system and parameters (#241)
- Introduced comprehensive capability management for services
- Added robust parameter validation for service configurations
- Enhanced service module flexibility and security
</Update>
<Update label="2025-09-03" description="v0.12.9" tags={["DID", "WebAuthn"]}>
Complete DID module WebAuthn and parameter implementation (#240)
- Full W3C WebAuthn Level 2 compliance with passwordless authentication
- Implemented CBOR-based attestation parsing
- Multi-algorithm signature verification (ES256, RS256, EdDSA)
- Added 9 new DID module parameters with validation
</Update>
<Update label="2025-09-03" description="v0.12.8" tags={["DWN", "Security", "IPFS"]}>
Introduce key rotation events and IPFS status endpoint (#238)
- Vault key rotation with Motor plugin integration
- Consensus-based encryption using validator set
- HMAC-SHA256 validation for data integrity
- IPFS status query endpoint with health metrics
</Update>
<Update label="2025-09-02" description="v0.12.7" tags={["Module Configuration"]}>
Implement module parameter validation and defaults (#237)
- Comprehensive parameter validation for DID and SVC modules
- Default parameters with FIDO2-compliant WebAuthn settings
- Enhanced parameter validation for service limits and timeouts
</Update>
<Update label="2025-08-30" description="v0.12.6" tags={["Events", "Modules"]}>
Complete remaining event emissions for DID and DWN modules (#235)
- Implemented typed Protobuf events for all state-changing operations
- Added detailed event types with enhanced observability
- Updated event emission patterns to follow Cosmos SDK v0.50.14 best practices
</Update>
<Update label="2025-08-27" description="v0.12.5" tags={["Events", "Protobuf"]}>
Implement typed Protobuf events for x/did, x/dwn, and x/svc modules (#233)
- Typed events following Cosmos SDK's ADR-032 pattern
- Event-driven application support with CometBFT websockets
- Backward compatibility maintained with legacy events
</Update>
<Update label="2025-08-24" description="v0.12.4" tags={["IBC", "DEX"]}>
Integrate Interchain Accounts for cross-chain DEX functionality
- Enhanced cross-chain interoperability for trading
- IBC integration for decentralized exchange operations
</Update>
<Update label="2025-08-24" description="v0.12.3" tags={["ICA", "DEX"]}>
Implement ICA Controller system in x/dex module for cross-chain DEX operations (#221)
- Full Interchain Account Controller implementation
- Cross-chain DEX trading capability
- Enhanced IBC protocol support
</Update>
<Update label="2025-08-20" description="v0.12.1" tags={["Testing", "Starship"]}>
Replace InterchainTest with Starship-based E2E testing framework (#217)
- Modern testing infrastructure with Starship
- Improved E2E test reliability and speed
- Better multi-chain testing support
</Update>
<Update label="2025-08-18" description="v0.12.0" tags={["Cryptography", "JWK"]}>
Add support for additional elliptic curves and JWK verification (#216)
- Extended elliptic curve support beyond secp256k1
- JSON Web Key (JWK) verification implementation
- Enhanced cryptographic flexibility
</Update>
---
<Update label="2025-08-18" description="v0.11.4" tags={["WebAuthn", "FIDO2"]}>
Complete WebAuthn/FIDO2 implementation for passwordless authentication (#215)
- Full FIDO2 compliance with passwordless authentication
- Hardware security key support
- Biometric authentication integration
</Update>
<Update label="2025-08-17" description="v0.11.3" tags={["DID", "W3C"]}>
Complete DID keeper implementation with W3C compliance and WebAuthn authentication (#214)
- Full W3C DID specification compliance
- WebAuthn integration for DID authentication
- Enhanced identity management capabilities
</Update>
<Update label="2025-08-16" description="v0.11.2" tags={["UI", "Monorepo"]}>
Transform UI package to shadcn monorepo architecture for uniform styling (#213)
- Migrated to shadcn component architecture
- Consistent design system across applications
- Improved component reusability
</Update>
<Update label="2025-08-15" description="v0.11.1" tags={["Security", "Memory"]}>
Improve secure memory handling for enhanced security (#201)
- Zero-memory clearing for sensitive data
- Protected memory allocation for cryptographic operations
- Enhanced key material security
</Update>
<Update label="2025-08-15" description="v0.11.0" tags={["Cryptography", "Security"]}>
Implement comprehensive cryptographic security enhancements (#200)
- Major cryptographic subsystem overhaul
- Enhanced encryption algorithms
- Improved key management system
</Update>
---
<Update label="2025-08-15" description="v0.10.34" tags={["CLI", "Wallet"]}>
Implement CLI commands for wallet module (#198)
- Comprehensive wallet management via CLI
- Transaction signing and broadcasting commands
- Key management operations
</Update>
<Update label="2025-08-14" description="v0.10.33" tags={["UCAN", "Wallet"]}>
Implement UCAN permission validation for wallet transactions (#197)
- User-Controlled Authorization Networks integration
- Permission-based transaction validation
- Enhanced wallet security model
</Update>
<Update label="2025-08-14" description="v0.10.32" tags={["SDK", "Go"]}>
Implement Go client SDK with transaction signing and broadcasting (#196)
- Complete Go SDK for chain interaction
- Transaction building and signing utilities
- gRPC and REST endpoint support
</Update>
<Update label="2025-08-13" description="v0.10.31" tags={["Docker", "Testnet"]}>
Enable Docker-based testnet execution
- Simplified testnet deployment via Docker
- Containerized node operation
- Quick local testing environment
</Update>
<Update label="2025-08-13" description="v0.10.28" tags={["Monorepo", "pnpm"]}>
Implement monorepo structure with pnpm workspaces and changesets (#189)
- Modern monorepo architecture
- pnpm workspace management
- Automated versioning with changesets
</Update>
<Update label="2025-08-12" description="v0.10.27" tags={["WebAuthn", "Gasless"]}>
Implement WebAuthn gasless transactions with comprehensive protocol integration (#186)
- Gasless onboarding for new users
- WebAuthn-based transaction signing
- Eliminated token requirement for registration
</Update>
<Update label="2025-08-11" description="v0.10.25" tags={["WebAuthn", "Security"]}>
Implement gasless WebAuthn registration with comprehensive security audit (#182)
- Security-audited gasless registration flow
- Anti-abuse mechanisms
- Credential uniqueness enforcement
</Update>
<Update label="2025-08-09" description="v0.10.24" tags={["DWN", "Encryption"]}>
Implement consensus-based encryption for DWN module (#181)
- Validator-based encryption keys
- Consensus-driven key management
- Enhanced data privacy
</Update>
<Update label="2025-08-09" description="v0.10.23" tags={["VRF", "Context"]}>
Enhance init command with VRF keypair generation and SonrContext system (#180)
- Verifiable Random Function integration
- SonrContext for session management
- Enhanced initialization process
</Update>
<Update label="2025-08-09" description="v0.10.22" tags={["Testing", "Refactor"]}>
Move interchain tests to dedicated location (#178)
- Improved test organization
- Separated integration tests
- Better test maintainability
</Update>
<Update label="2025-08-08" description="v0.10.20" tags={["Motor", "WASM", "MPC"]}>
Refactor Motor WASM plugin as MPC-based UCAN source (#177)
- Multi-party computation integration
- WASM-based secure execution
- UCAN capability management
</Update>
<Update label="2025-08-08" description="v0.10.19" tags={["Documentation", "UCAN"]}>
Migrate documentation to Mintlify structure (#172) and migrate x/ucan module to internal library (#174)
- Documentation platform migration
- UCAN module refactoring
- Improved code organization
</Update>
<Update label="2025-08-06" description="v0.10.17" tags={["WebAuthn", "CLI"]}>
Implement WebAuthn CLI registration with gasless transactions (#168)
- CLI-based WebAuthn registration
- Browser integration for credential creation
- Gasless onboarding flow
</Update>
<Update label="2025-08-06" description="v0.10.16" tags={["DWN", "Security"]}>
Implement auto-create DWN vault with comprehensive security improvements (#161)
- Automatic vault provisioning
- Enhanced security measures
- Improved user onboarding
</Update>
<Update label="2025-08-05" description="v0.10.15" tags={["Highway", "WebSocket"]}>
Migrate Highway service to Echo framework with WebSocket/SSE and JWT auth (#159)
- Echo framework migration
- Real-time WebSocket support
- JWT authentication system
</Update>
<Update label="2025-08-05" description="v0.10.14" tags={["Highway", "Asynq"]}>
Complete Highway proxy server implementation with asynq and proto.Actor (#157)
- Asynq task queue integration
- Actor-based concurrency model
- Improved task processing
</Update>
<Update label="2025-08-05" description="v0.10.13" tags={["DWN", "Gasless"]}>
Refactor x/dwn vaults and introduce gasless transactions (#154)
- Vault system refactoring
- Gasless transaction support
- Enhanced user experience
</Update>
<Update label="2025-08-03" description="v0.10.12" tags={["Monorepo", "CI/CD"]}>
Monorepo restructure with internal packages and enhanced CI/CD (#151)
- Internal package architecture
- CI/CD pipeline improvements
- Better code organization
</Update>
<Update label="2025-08-02" description="v0.10.9" tags={["Testnet", "Infrastructure"]}>
Enhance testnet configuration with faucet and explorer settings (#145)
- Testnet faucet integration
- Block explorer configuration
- Improved developer experience
</Update>
<Update label="2025-08-01" description="v0.10.8" tags={["Deployment", "Infrastructure"]}>
Optimize deployment workflows and update infrastructure configuration (#141)
- Streamlined deployment process
- Infrastructure updates
- Performance optimizations
</Update>
<Update label="2025-08-01" description="v0.10.6" tags={["Starship", "Network"]}>
Introduce Starship network configurations for devnet and testnet (#139)
- Starship integration for local development
- Multi-network configuration support
- Simplified network management
</Update>
<Update label="2025-07-31" description="v0.10.3" tags={["Docker", "Build"]}>
Streamline Docker build for enhanced efficiency (#136)
- Optimized Docker build process
- Reduced image sizes
- Faster build times
</Update>
<Update label="2025-07-31" description="v0.10.2" tags={["Starship", "Development"]}>
Streamline starship configuration and local development (#135)
- Simplified Starship setup
- Enhanced local development workflow
- Better developer experience
</Update>
<Update label="2025-07-31" description="v0.10.1" tags={["CI/CD", "Wallet", "EVM"]}>
Major infrastructure and wallet improvements (#134, #131, #128, #127)
- Optimized CI/CD workflows with smart testing
- Fee grant integration with BasicAllowance
- EVM transaction support in wallet module
- External wallet linking as DID assertion methods
</Update>
<Update label="2025-07-21" description="v0.10.0" tags={["Security", "WASM"]}>
Implement secure key management with WASM enclaves (#126)
- WASM-based secure enclaves
- Hardware-level key protection
- Enhanced cryptographic isolation
</Update>
---
<Update label="2025-07-21" description="v0.9.22" tags={["Vault", "IPFS"]}>
Implement vault export/import with IPFS encryption (#125)
- IPFS-based vault backup
- Encrypted vault exports
- Decentralized storage integration
</Update>
<Update label="2025-07-20" description="v0.9.20" tags={["Transactions", "Release"]}>
Add transaction building framework and streamline release process (#123)
- Comprehensive transaction builder
- Automated release pipeline
- Improved developer tools
</Update>
<Update label="2025-07-20" description="v0.9.19" tags={["Testing", "CI"]}>
Add cross-module keeper integration tests and optimize CI performance (#122)
- Cross-module testing framework
- CI pipeline optimization
- Better test coverage
</Update>
<Update label="2025-07-20" description="v0.9.18" tags={["Service", "UCAN"]}>
Improve service validation and UCAN integration (#121)
- Enhanced service validation logic
- UCAN capability improvements
- Better error handling
</Update>
<Update label="2025-07-20" description="v0.9.17" tags={["DWN", "Service"]}>
Implement ServiceKeeper interface for x/dwn module (#120)
- Service abstraction layer
- Improved module interactions
- Enhanced modularity
</Update>
<Update label="2025-07-20" description="v0.9.16" tags={["DWN", "UCAN"]}>
Implement UCANKeeper interface for x/dwn module (#119)
- UCAN integration for DWN
- Capability-based permissions
- Enhanced authorization
</Update>
<Update label="2025-07-18" description="v0.9.15" tags={["Service", "UCAN"]}>
Implement UCANKeeper interface for x/svc module (#117)
- Service module UCAN support
- Permission management
- Improved security model
</Update>
<Update label="2025-07-18" description="v0.9.14" tags={["Service", "DID"]}>
Implement DIDKeeper interface for x/svc module (#116)
- DID integration for services
- Identity-based service management
- Enhanced authentication
</Update>
<Update label="2025-07-18" description="v0.9.11" tags={["Service", "Keeper"]}>
Implement ServiceKeeper interface methods in x/svc keeper (#113)
- Complete service keeper implementation
- Core service functionality
- Module integration
</Update>
<Update label="2025-07-18" description="v0.9.10" tags={["UCAN", "Error Handling"]}>
Implement UCANKeeper interface methods and centralize error handling (#112)
- UCAN keeper implementation
- Centralized error management
- Improved code maintainability
</Update>
<Update label="2025-07-18" description="v0.9.9" tags={["DID", "Signatures"]}>
Implement VerifyDIDDocumentSignature method with multi-algorithm support (#111)
- Multi-algorithm signature verification
- Ed25519, ECDSA, RSA support
- Enhanced DID security
</Update>
<Update label="2025-07-18" description="v0.9.8" tags={["Wallet", "Architecture"]}>
Implement wallet derivation and keeper interface architecture (#110)
- HD wallet derivation
- Keeper interface design
- Improved wallet architecture
</Update>
<Update label="2025-07-16" description="v0.9.6" tags={["Vault", "Interface"]}>
Introduce VaultKeeper interface for enhanced modularity (#99)
- Vault abstraction layer
- Improved code organization
- Better testability
</Update>
<Update label="2025-07-15" description="v0.9.5" tags={["DWN", "Vault"]}>
Enable DWN vault spawning via query API and add comprehensive tests (#98)
- Query-based vault creation
- Comprehensive test suite
- API improvements
</Update>
<Update label="2025-07-14" description="v0.9.4" tags={["Testnet", "DAO"]}>
Update testnet configuration for DAO governance (#84)
- DAO governance integration
- Testnet parameter updates
- Governance readiness
</Update>
<Update label="2025-07-09" description="v0.9.3" tags={["Vault", "Actor"]}>
Centralize vault actor system and optimize plugin management (#83)
- Actor system centralization
- Plugin optimization
- Performance improvements
</Update>
<Update label="2025-07-06" description="v0.9.0" tags={["DWN", "WASM"]}>
Refactor x/dwn module structure and integrate WebAssembly motor client (#81)
- Major DWN module refactoring
- WASM motor client integration
- Enhanced documentation
</Update>
---
<Update label="2025-07-05" description="v0.8.12" tags={["Analytics", "Documentation"]}>
Implement Rybbit analytics and update documentation site styling (#80)
- Analytics integration
- Documentation improvements
- Better user insights
</Update>
<Update label="2025-07-04" description="v0.8.11" tags={["UI", "Migration"]}>
Complete shadcn/TemplUI migration from NebulaUI (#79)
- UI library migration
- Modern component system
- Improved styling
</Update>
<Update label="2025-07-02" description="v0.8.2" tags={["Documentation", "Branding"]}>
Enhanced documentation landing page with custom branding (#69)
- Custom branding implementation
- Improved documentation UI
- Better user experience
</Update>
<Update label="2025-07-02" description="v0.8.0" tags={["Quality", "Linting"]}>
Integrate Trunk.io for code quality and linting (#65)
- Trunk.io integration
- Automated code quality checks
- Enhanced linting rules
</Update>
---
<Update label="2025-07-01" description="v0.7.0" tags={["DWN", "DIF"]}>
Implement DWN module with enclave signing and DIF specification (#64)
- Decentralized Web Node implementation
- DIF specification compliance
- Enclave-based signing
</Update>
---
<Update label="2025-07-01" description="v0.6.1" tags={["Protobuf", "Client"]}>
ES-client protobuf generation (#63)
- JavaScript client protobuf support
- Improved client SDK
- Better developer tools
</Update>
<Update label="2025-07-01" description="v0.6.0" tags={["API", "Documentation"]}>
Automated API Reference Generation for Cosmos Modules and Highway REST Service (#62)
- Automated API documentation
- REST service documentation
- Improved developer resources
</Update>
---
<Update label="2025-06-30" description="v0.5.1" tags={["TUI", "Dashboard"]}>
Enhance TUI Dashboard with real-time data visualization and testnet support (#59)
- Real-time data visualization
- Testnet dashboard support
- Enhanced monitoring
</Update>
<Update label="2025-06-30" description="v0.5.0" tags={["UCAN", "Handlers"]}>
Implement x/ucan msgServer handlers with capability templates (#55)
- UCAN message handlers
- Capability templates
- Authorization framework
</Update>
---
<Update label="2025-06-30" description="v0.4.1" tags={["UI", "Components"]}>
Integrate Nebula UI Component Library (#54)
- UI component library integration
- Reusable components
- Design consistency
</Update>
<Update label="2025-06-29" description="v0.4.0" tags={["DID", "WebAuthn", "Testing"]}>
W3C DID Controller with WebAuthn support and comprehensive testing improvements (#52)
- W3C DID controller implementation
- WebAuthn authentication
- Enhanced test coverage
</Update>
---
<Update label="2025-06-29" description="v0.3.0" tags={["UCAN", "Migration"]}>
Migrate UCAN capability definitions to x/ucan module (#49)
- UCAN module creation
- Capability migration
- Improved architecture
</Update>
---
<Update label="2025-06-28" description="v0.2.0" tags={["DNS", "UCAN"]}>
Implement DNS record verification with UCAN delegation for x/svc (#41)
- DNS verification system
- UCAN-based delegation
- Service authentication
</Update>
---
<Update label="2025-06-28" description="v0.1.0" tags={["Highway", "API"]}>
Implement Highway Service API Handlers (#39)
- Highway service implementation
- API handler creation
- Core service functionality
</Update>
<Update label="2025-06-26" description="v0.0.23" tags={["IPFS", "CI/CD", "Documentation"]}>
Major infrastructure and documentation improvements (#38, #37, #36)
- IPFS private network support
- Enhanced CI/CD workflows
- Comprehensive tokenomics documentation
- Client integration guide
- Research section with whitepapers
</Update>
<Update label="2025-06-22" description="v0.0.1" tags={["Initial", "Core"]}>
Initial release with core blockchain features
- Automated version bumping and changelog generation
- Highway service for enhanced authentication
- Database migration using goose
- CosmWasm VM for smart contracts
- IPFS Kubo v0.35.0 integration
- Decentralized web node runtime with WASM enclave
- Complete database schema for core entities
</Update>
docs/concepts/hway.mdx
+375
View File
@@ -0,0 +1,375 @@
---
title: "Highway Service"
sidebarTitle: "Hway Overview"
description: "High-performance task processing service for Sonr's decentralized vault system"
icon: "play"
---
# Highway Service (hway)
Highway is a high-performance task processing service for Sonr's decentralized vault system. It provides asynchronous, durable execution of cryptographic operations using WebAssembly enclaves and Redis-backed job queues.
## Overview
Highway acts as a distributed task processor that handles secure cryptographic operations for the Sonr blockchain ecosystem. It leverages:
- **Asynq** for reliable job queue management with Redis
- **Proto.Actor** for actor-based concurrency
- **WebAssembly enclaves** for secure cryptographic operations
- **IPFS integration** for decentralized storage
## Quick Start
### Prerequisites
- Redis server running on `127.0.0.1:6379`
- Go 1.24.4 or later
### Installation
```bash
# Build and install the Highway service
make install
# Or build directly
cd cmd/hway
go build -o hway .
```
### Running the Service
```bash
# Start the Highway service
./hway
```
The service will connect to Redis and begin processing vault tasks with the following configuration:
- **Concurrency**: 10 workers
- **Queue Priorities**:
- `critical`: 6 workers
- `default`: 3 workers
- `low`: 1 worker
## Architecture
Highway implements a multi-layered architecture for secure task processing:
```
Task Queue Highway Service Vault Actor
(Redis) (Asynq) (Proto.Actor)
WASM Enclave
(Extism)
```
### Core Components
1. **Task Processing Layer** (`main.go`)
- Asynq server configuration
- Task routing and worker management
- Redis connection handling
2. **Actor System** (`internal/vault/plugin/actor.go`)
- Proto.Actor based concurrency
- Behavioral state management
- Lifecycle management for WASM plugins
3. **Plugin Interface** (`internal/vault/plugin/plugin.go`)
- WebAssembly plugin abstraction
- Secure cryptographic operations
- Type-safe method calls
4. **Task Definitions** (`internal/vault/tasks/`)
- Task type definitions
- Payload serialization
- Task processing logic
## Supported Operations
Highway supports the following cryptographic operations through its vault system:
### Key Generation
```go
// Generate a new cryptographic key pair
type GenerateRequest struct {
ID string `json:"id"`
}
type GenerateResponse struct {
Data *mpc.EnclaveData `json:"data"`
PublicKey []byte `json:"public_key"`
}
```
### Digital Signatures
```go
// Sign a message
type SignRequest struct {
Message []byte `json:"message"`
Enclave *mpc.EnclaveData `json:"enclave"`
}
type SignResponse struct {
Signature []byte `json:"signature"`
}
```
### Signature Verification
```go
// Verify a signature
type VerifyRequest struct {
PublicKey []byte `json:"public_key"`
Message []byte `json:"message"`
Signature []byte `json:"signature"`
}
type VerifyResponse struct {
Valid bool `json:"valid"`
}
```
### Vault Management
#### Export to IPFS
```go
type ExportRequest struct {
Enclave *mpc.EnclaveData `json:"enclave,omitempty"`
Password []byte `json:"password,omitempty"`
}
type ExportResponse struct {
CID string `json:"cid,omitempty"`
Success bool `json:"success"`
}
```
#### Import from IPFS
```go
type ImportRequest struct {
CID string `json:"cid,omitempty"`
Password []byte `json:"password,omitempty"`
}
type ImportResponse struct {
Enclave *mpc.EnclaveData `json:"enclave,omitempty"`
Success bool `json:"success"`
}
```
#### Vault Refresh
```go
type RefreshRequest struct {
Enclave *mpc.EnclaveData `json:"enclave,omitempty"`
}
type RefreshResponse struct {
Okay bool `json:"okay"`
Data *mpc.EnclaveData `json:"data,omitempty"`
}
```
## Task Management
### Creating Tasks
Tasks are created using the Asynq task creation utilities:
```go
import "github.com/sonr-io/sonr/internal/vault/tasks"
// Create a vault generation task
task, err := tasks.NewVaultGenerateTask(userID)
if err != nil {
return err
}
// Enqueue the task
client := asynq.NewClient(asynq.RedisClientOpt{Addr: "127.0.0.1:6379"})
info, err := client.Enqueue(task)
```
### Task Types
Highway currently supports the following task types:
- `vault:generate` - Generate new cryptographic key pairs
Additional task types can be registered by:
1. Defining the task type constant in `internal/vault/tasks/types.go`
2. Creating appropriate payload and response structures
3. Implementing the task processor
4. Registering the handler in `main.go`
## Configuration
### Redis Configuration
Highway connects to Redis using the following default settings:
```go
const redisAddr = "127.0.0.1:6379"
```
### Worker Configuration
```go
asynq.Config{
Concurrency: 10,
Queues: map[string]int{
"critical": 6, // High priority tasks
"default": 3, // Normal priority tasks
"low": 1, // Low priority tasks
},
}
```
### Actor System Configuration
```go
const KRequestTimeout = 20 * time.Second
```
## Security Model
Highway implements a multi-layered security approach:
1. **WebAssembly Isolation**: All cryptographic operations run in WASM enclaves
2. **Actor Encapsulation**: Each vault actor maintains isolated state
3. **Encrypted Storage**: Vault data is encrypted before IPFS storage
4. **Password Protection**: Additional password layer for import/export operations
5. **Request Validation**: All requests undergo validation before processing
## Development
### Adding New Task Types
1. **Define the task type**:
```go
// In internal/vault/tasks/types.go
const TypeNewOperation = "vault:new_operation"
```
2. **Create payload structures**:
```go
type NewOperationPayload struct {
Field1 string `json:"field1"`
Field2 int `json:"field2"`
}
func NewNewOperationTask(field1 string, field2 int) (*asynq.Task, error) {
payload, err := json.Marshal(NewOperationPayload{
Field1: field1,
Field2: field2,
})
if err != nil {
return nil, err
}
return asynq.NewTask(TypeNewOperation, payload), nil
}
```
3. **Implement the processor**:
```go
func (processor *VaultProcessor) ProcessNewOperation(ctx context.Context, t *asynq.Task) error {
var p NewOperationPayload
if err := json.Unmarshal(t.Payload(), &p); err != nil {
return fmt.Errorf("json.Unmarshal failed: %v: %w", err, asynq.SkipRetry)
}
// Process the task
// ...
return nil
}
```
4. **Register the handler**:
```go
// In main.go
mux.Handle(tasks.TypeNewOperation, tasks.NewVaultProcessor())
```
### Testing
Highway includes comprehensive test suites for:
- Task processing logic
- Actor system behavior
- WASM plugin integration
- Redis queue operations
Run tests with:
```bash
make test-vaults
```
## Monitoring and Observability
Highway provides detailed logging for:
- Task processing events
- Actor lifecycle management
- Plugin operation results
- Error conditions and recovery
All logs use structured logging with slog for consistent formatting and filtering.
## Performance Considerations
- **Concurrency**: Adjust worker count based on CPU cores and workload
- **Queue Priorities**: Balance task priorities according to business requirements
- **Redis Memory Usage**: Monitor Redis memory consumption with large task volumes
- **WASM Performance**: Plugin operations are CPU-intensive; size workers accordingly
## Troubleshooting
### Common Issues
**Redis Connection Failed**
```
could not run server: dial tcp 127.0.0.1:6379: connect: connection refused
```
- Ensure Redis server is running on the configured address
- Check Redis configuration and network connectivity
**Plugin Load Failed**
```
failed to create enclave host: plugin load error
```
- Verify WASM plugin file exists and is accessible
- Check plugin manifest configuration
- Review Extism runtime requirements
**Actor Initialization Failed**
```
Enclave actor failed to start
```
- Review plugin loading prerequisites
- Check system memory and resource availability
- Verify Proto.Actor system configuration
docs/concepts/motr.mdx
+114
View File
@@ -0,0 +1,114 @@
---
title: "Motr WASM Light-Node"
sidebarTitle: "Motr Overview"
description: "Learn how to use the Motor WASM plugin as an MPC-based UCAN source for decentralized token operations"
icon: "play"
---
# Motor WASM Plugin: UCAN Source
The Motor WASM plugin is a WebAssembly-based plugin that provides Multi-Party Computation (MPC) powered UCAN (User-Controlled Authorization Networks) token generation and management.
## Overview
The Motor plugin enables secure, decentralized token creation and management through an MPC-based architecture. It provides the following key capabilities:
- Secure token generation
- MPC-based signing
- Flexible UCAN token creation
- Integrated enclave management
## Environment Configuration
To use the Motor plugin, you need to set the following PDK environment variables:
```json
{
"chain_id": "sonr-testnet-1", // Blockchain network
"enclave": { ... }, // MPC enclave configuration
"vault_config": { ... } // Optional vault configuration
}
```
## UCAN Token Creation
### Creating Origin Tokens
```go
type NewOriginTokenRequest struct {
AudienceDID string // Target DID
Attenuations []map[string]any // Optional restrictions
Facts []string // Additional claims
NotBefore int64 // Token activation time
ExpiresAt int64 // Token expiration time
}
```
Example usage:
```go
request := NewOriginTokenRequest{
AudienceDID: "did:example:target-did",
Attenuations: []{
{"capability": "read", "resource": "/data"}
},
Facts: ["authenticated_user"],
NotBefore: time.Now().Unix(),
ExpiresAt: time.Now().Add(24 * time.Hour).Unix()
}
```
### Creating Attenuated Tokens
```go
type NewAttenuatedTokenRequest struct {
ParentToken string // Previous token to derive from
AudienceDID string // Target DID
Attenuations []map[string]any // Token restrictions
Facts []string // Additional claims
NotBefore int64 // Token activation time
ExpiresAt int64 // Token expiration time
}
```
## Signing and Verification
The Motor plugin provides methods for data signing and verification:
```go
// Sign data using MPC enclave
func SignData(data []byte) (signature []byte, err error)
// Verify signed data
func VerifyData(data, signature []byte) (valid bool, err error)
```
## Error Handling
The plugin returns structured error responses with detailed error messages:
```go
type UCANTokenResponse struct {
Token string // Generated token
Issuer string // Token issuer DID
Address string // Blockchain address
Error string // Error message (if any)
}
```
## Best Practices
1. Always validate the enclave before generating tokens
2. Use the shortest possible token lifetime
3. Implement granular attenuations
4. Validate tokens before using them
## Security Considerations
- MPC ensures no single party controls the entire signing process
- Tokens are cryptographically signed using distributed key shares
- Supports multiple key types: Ed25519, Secp256k1, RSA
## Advanced Configuration
For advanced MPC enclave configurations, refer to the DWN configuration documentation.
docs/concepts/sonr.mdx
+36
View File
@@ -0,0 +1,36 @@
---
title: The Blockchain for Self-Sovereign Identity
sidebarTitle: Sonr Overview
description: A deep dive into Sonr's novel approach to personal data ownership and control.
icon: play
---
In a world rapidly approaching the era of quantum computing, traditional cryptographic methods face unprecedented challenges. The burden of securing digital identity can no longer rest solely on the user. Sonr is designed to simplify the user experience while providing far greater security over personal data. We achieve this by incorporating the following concepts into our identity primitive.
## Core Concepts
<CardGroup>
<Card title="Multi-Party Computation (MPC)">
We eliminate the need for users to manage private keys directly. Instead, we
use rotating key shares with the DKLS algorithm to construct digital
signatures, distributing trust and removing single points of failure.
</Card>
<Card title="Identifier Accumulators">
Accounts on Sonr are anonymous and private by default. We employ
zero-knowledge accumulators to achieve this, allowing for verifiable claims
without revealing underlying identities.
</Card>
<Card title="On-Chain Wallet Interface">
The public key of a Sonr Account is encoded with bech32 and persisted
on-chain. This makes accounts highly resilient and resolvable across all
validator nodes, creating a robust digital profile.
</Card>
</CardGroup>
By combining these concepts, we achieve a portable, interoperable, and secure identifier that we define as a **Sonr Account**.
## The Sonr Approach to Identity
The Sonr platform approaches user authentication with the understanding that a user's identity is multi-dimensional and must be safeguarded with the utmost integrity. This is achieved through the implementation of **Decentralized Identifiers (DIDs)** and **Multi-Party Computation (MPC)**, creating a robust framework for identity management.
DIDs are a cornerstone of the Sonr identity system, providing a verifiable and self-sovereign identity that users control entirely. This decentralized identity is not just a static entity but a dynamic one, capable of interfacing securely with various facets of the Sonr ecosystem. The MPC component further enhances security by ensuring that the private keys, the quintessential element of user authentication, are never fully exposed, even during the authentication process.
docs/concepts/token.mdx
+82
View File
@@ -0,0 +1,82 @@
---
title: $SNR Economics
description: "The role of tokenomics in the Sonr ecosystem is twofold: it provides a medium of exchange and serves as a reward mechanism for validators. The platform's native tokens are used to facilitate transactions, secure network integrity, and incentivize behaviors that contribute to the network's longevity and reliability."
sidebarTitle: "Design Model"
icon: "star"
---
<Note>
The Sonr platform has implemented a sophisticated token handling and treasury process designed to ensure the stability and sustainability of the SNR token. This process is critical in managing the economics of the Sonr ecosystem and ensuring its long-term viability.
</Note>
## Key Economic Processes
<CardGroup>
<Card title="Buyback Process for Non-SNR Payments">
When payments are made in currencies other than SNR, the Sonr system
initiates a buyback process. This approach involves using the received
non-SNR currency to purchase SNR tokens from the open market. This mechanism
supports the demand and market value of SNR tokens and ensures a consistent
influx of SNR into the system, reinforcing its utility and circulation
within the ecosystem.
</Card>
<Card title="Contribution to SNR Fee Pool">
The SNR tokens acquired through the buyback process are contributed to the
SNR fee pool. This pool plays a pivotal role in the ecosystem, as it is
utilized for various operational purposes, including network transaction
fees, rewards for validators, and other ecosystem incentives. This
continuous replenishment of the fee pool ensures the smooth operation and
sustainability of the network's economic activities.
</Card>
<Card title="Allocation to the Treasury">
Half of the unvested tokens, representing 50% of the total, are allocated to
the Sonr treasury. This treasury acts as a strategic reserve, supporting the
long-term objectives of the Sonr ecosystem. Funds from the treasury can be
utilized for various purposes, including development initiatives, marketing
efforts, community growth, and other activities that align with Sonr’s
strategic goals and contribute to the overall growth and success of the
platform.
</Card>
<Card title="Scaling Inflation Rewards">
To ensure the equitable distribution of incentives and maintain a balanced
economic model, Sonr has implemented a system where inflation rewards scale
relative to the authentic growth of its user base. This approach means that
as the number of genuine users on the platform increases, so do the
inflation rewards. This scaling mechanism aligns the incentives with actual
platform usage, fostering an environment where growth in the user base
directly contributes to the overall health and stability of the token
economy.
</Card>
</CardGroup>
## Validator Incentives
Validators play a pivotal role in the network, responsible for processing authentication requests and maintaining the blockchain's integrity. They are incentivized through a task claiming process based on a first-come-first-serve mechanism and are remunerated via transaction fees and token rewards. This incentive structure ensures the high performance and reliability of services within the network.
<CardGroup>
<Card title="Task Claiming">
Validators select tasks from the Order Stack on a first-come-first-serve
basis, ensuring a fair and efficient distribution of work.
</Card>
<Card title="Delivery and Payment">
If a validator successfully delivers a service request, they proceed to the
payment process. The payment is provided with a vesting schedule, aligning
the validators' incentives with the long-term health of the network.
</Card>
<Card title="Slashing Conditions">
In instances where a validator fails to deliver on a service request, a
slashing condition is triggered. This condition serves as a deterrent
against poor performance and ensures the reliability of services within the
network.
</Card>
<Card title="Consequences of Failure">
Failure to deliver a service results in the slashing and burning of the
validator's staked SNR tokens. This punitive measure reinforces the
commitment of validators to fulfill their tasks diligently and efficiently.
</Card>
</CardGroup>
docs/docs.json
+366
View File
@@ -0,0 +1,366 @@
{
"$schema": "https://mintlify.com/docs.json",
"theme": "maple",
"name": "Sonr Docs",
"logo": {
"light": "https://cdn.sonr.io/logos/docs/logo.svg",
"dark": "https://cdn.sonr.io/logos/docs/logo-dark.svg"
},
"favicon": "https://cdn.sonr.io/favicon.ico",
"colors": {
"primary": "#17c2FF",
"light": "#17c2FF",
"dark": "#279cff"
},
"icons": {
"library": "lucide"
},
"navigation": {
"dropdowns": [
{
"dropdown": "Documentation",
"description": "Sonr Fundamentals",
"icon": "lightbulb",
"pages": [
{
"group": "Getting Started",
"icon": "rocket",
"pages": [
"index",
"reference/install",
"changelog",
"faq"
]
},
{
"group": "Learn Concepts",
"icon": "lightbulb",
"pages": [
{
"group": "Sonr Blockchain",
"icon": "combine",
"pages": ["concepts/sonr", "modules/did/index", "modules/dwn/index", "modules/svc/index", "modules/dex/index"]
},
{
"group": "Gateway Services",
"icon": "radio-tower",
"pages": [
"concepts/hway",
"concepts/gasless-onboarding",
"concepts/webauthn-integration"
]
},
{
"group": "Light Clients",
"icon": "plug",
"pages": [
"concepts/motr",
"concepts/decentralized-auth",
"concepts/identity-generation",
"concepts/dwn-architecture"
]
},
{
"group": "Token Economics",
"icon": "coins",
"pages": [
"concepts/token",
"economics/values",
"economics/utility",
"economics/staking",
"economics/rewards",
"economics/governance",
"economics/distribution"
]
}
]
},
{
"group": "Build Apps",
"icon": "hammer",
"pages": [
{
"group": "Client SDKs",
"icon": "code",
"pages": [
"quickstart/react",
"quickstart/browser",
"quickstart/golang"
]
},
{
"group": "Service Management",
"icon": "globe",
"pages": [
"guides/register-records",
"guides/authorize-clients",
"guides/broadcast-transactions",
"guides/issue-payments",
"guides/establish-connection"
]
}
]
},
{
"group": "Validator Guides",
"icon": "shield-check",
"pages": [
"guides/onboarding",
"guides/development",
"guides/deployment",
{
"group": "Security Report",
"icon": "shield",
"pages": [
"reference/security/audit-report",
"reference/security/compliance",
"reference/security/cryptography",
"reference/security/vulnerabilities"
]
}
]
},
{
"group": "Next Steps",
"icon": "play",
"pages": []
}
]
},
{
"dropdown": "Reference",
"description": "API Reference",
"icon": "code",
"pages": [
{
"group": "CLI Commands",
"icon": "terminal",
"root": "cli-commands",
"pages": [
"reference/commands/snrd",
"reference/commands/snrd_auth",
"reference/commands/snrd_auth_register",
"reference/commands/snrd_genesis",
"reference/commands/snrd_genesis_add-genesis-account",
"reference/commands/snrd_genesis_collect-gentxs",
"reference/commands/snrd_genesis_export",
"reference/commands/snrd_genesis_gentx",
"reference/commands/snrd_genesis_init",
"reference/commands/snrd_genesis_migrate",
"reference/commands/snrd_genesis_validate",
"reference/commands/snrd_help",
"reference/commands/snrd_init",
"reference/commands/snrd_keys",
"reference/commands/snrd_keys_add",
"reference/commands/snrd_keys_delete",
"reference/commands/snrd_keys_export",
"reference/commands/snrd_keys_import",
"reference/commands/snrd_keys_list",
"reference/commands/snrd_keys_migrate",
"reference/commands/snrd_keys_parse",
"reference/commands/snrd_keys_show",
"reference/commands/snrd_migrate",
"reference/commands/snrd_node",
"reference/commands/snrd_prune",
"reference/commands/snrd_query",
"reference/commands/snrd_query_account",
"reference/commands/snrd_query_accounts",
"reference/commands/snrd_query_auth",
"reference/commands/snrd_query_bank",
"reference/commands/snrd_query_consensus",
"reference/commands/snrd_query_delegation",
"reference/commands/snrd_query_did",
"reference/commands/snrd_query_distribution",
"reference/commands/snrd_query_dwn",
"reference/commands/snrd_query_feegrant",
"reference/commands/snrd_query_gov",
"reference/commands/snrd_query_slashing",
"reference/commands/snrd_query_staking",
"reference/commands/snrd_query_svc",
"reference/commands/snrd_query_tendermint",
"reference/commands/snrd_query_tx",
"reference/commands/snrd_rollback",
"reference/commands/snrd_status",
"reference/commands/snrd_tendermint",
"reference/commands/snrd_tx",
"reference/commands/snrd_tx_bank",
"reference/commands/snrd_tx_consensus",
"reference/commands/snrd_tx_crisis",
"reference/commands/snrd_tx_did",
"reference/commands/snrd_tx_distribution",
"reference/commands/snrd_tx_dwn",
"reference/commands/snrd_tx_feegrant",
"reference/commands/snrd_tx_gov",
"reference/commands/snrd_tx_slashing",
"reference/commands/snrd_tx_staking",
"reference/commands/snrd_tx_svc",
"reference/commands/snrd_version"
]
},
{
"group": "Decentralized Exchange",
"icon": "arrow-right-left",
"tag": "x/dex",
"pages": [
{
"group": "HTTP Endpoints",
"tag": "Query",
"icon": "rss",
"pages": [
"api-reference/dex/get-dex-account",
"api-reference/dex/get-module-parameters",
"api-reference/dex/get-pool-information",
"api-reference/dex/get-remote-chain-balance",
"api-reference/dex/get-transaction-history",
"api-reference/dex/list-all-dex-accounts",
"api-reference/dex/list-orders"
]
},
{
"group": "GRPC Methods",
"tag": "TxMsg",
"icon": "plug",
"pages": [
"api-reference/dex/add-liquidity",
"api-reference/dex/cancel-order",
"api-reference/dex/create-dex-account",
"api-reference/dex/create-limit-order",
"api-reference/dex/execute-token-swap",
"api-reference/dex/remove-liquidity"
]
}
]
},
{
"group": "Decentralized Identifiers",
"icon": "contact-round",
"tag": "x/did",
"pages": [
{
"group": "HTTP Endpoints",
"tag": "Query",
"icon": "rss",
"pages": [
"api-reference/did/get-all-credentials-by-did",
"api-reference/did/get-did-document",
"api-reference/did/get-dids-by-controller",
"api-reference/did/get-module-parameters",
"api-reference/did/get-service-endpoint",
"api-reference/did/get-verifiable-credential",
"api-reference/did/get-verification-method",
"api-reference/did/list-all-did-documents",
"api-reference/did/list-verifiable-credentials",
"api-reference/did/resolve-did"
]
},
{
"group": "GRPC Methods",
"tag": "TxMsg",
"icon": "plug",
"pages": [
"api-reference/did/add-service-endpoint",
"api-reference/did/add-verification-method",
"api-reference/did/create-did-document",
"api-reference/did/deactivate-did",
"api-reference/did/issue-verifiable-credential",
"api-reference/did/link-external-wallet",
"api-reference/did/register-webauthn-credential-gasless",
"api-reference/did/remove-service-endpoint",
"api-reference/did/remove-verification-method",
"api-reference/did/revoke-verifiable-credential",
"api-reference/did/update-did-document",
"api-reference/did/update-module-parameters"
]
}
]
},
{
"group": "Decentralized Web Nodes",
"icon": "wallet",
"tag": "x/dwn",
"pages": [
{
"group": "HTTP Endpoints",
"tag": "Query",
"icon": "rss",
"pages": [
"api-reference/dwn/query-dwn-permissions",
"api-reference/dwn/query-dwn-protocols",
"api-reference/dwn/query-dwn-records",
"api-reference/dwn/query-encrypted-record-with-decryption",
"api-reference/dwn/query-encryption-system-status",
"api-reference/dwn/query-ipfs-node-status",
"api-reference/dwn/query-module-parameters",
"api-reference/dwn/query-specific-dwn-record",
"api-reference/dwn/query-specific-dwn-protocol",
"api-reference/dwn/query-specific-vault",
"api-reference/dwn/query-vaults-by-owner",
"api-reference/dwn/query-vrf-consensus-contributions",
"api-reference/dwn/retrieve-ipfs-content-by-cid"
]
},
{
"group": "GRPC Methods",
"tag": "TxMsg",
"icon": "plug",
"pages": [
"api-reference/dwn/configure-dwn-protocol",
"api-reference/dwn/delete-record-from-dwn",
"api-reference/dwn/grant-dwn-permission",
"api-reference/dwn/revoke-dwn-permission",
"api-reference/dwn/rotate-vault-encryption-keys",
"api-reference/dwn/update-dwn-module-parameters",
"api-reference/dwn/write-record-to-dwn"
]
}
]
},
{
"group": "Service Registry",
"icon": "shield-check",
"tag": "x/svc",
"pages": [
{
"group": "HTTP Endpoints",
"tag": "Query",
"icon": "rss",
"pages": [
"api-reference/svc/query-domain-verification-status",
"api-reference/svc/query-module-parameters",
"api-reference/svc/query-service-by-id",
"api-reference/svc/query-services-by-domain",
"api-reference/svc/query-services-by-owner"
]
},
{
"group": "GRPC Methods",
"tag": "TxMsg",
"icon": "plug",
"pages": [
"api-reference/svc/complete-domain-verification",
"api-reference/svc/initiate-domain-verification",
"api-reference/svc/register-service-with-verified-domain",
"api-reference/svc/update-module-parameters"
]
}
]
}
]
}
]
},
"footer": {
"socials": {
"discord": "https://sonr.io/discord",
"github": "https://github.com/sonr-io",
"twitter": "https://twitter.com/sonr_io",
"youtube": "https://youtube.com/@sonrhq",
"website": "https://sonr.io"
}
},
"integrations": {
"ga4": {
"measurementId": "G-FY0WZBSGH8"
}
}
}
docs/faq.mdx
+121
View File
@@ -0,0 +1,121 @@
---
title: "Frequently Asked Questions"
sidebarTitle: "FAQ"
description: "A Collection of commonly asked questions about Sonr"
icon: "life-buoy"
---
<iframe
width="750"
height="422"
src="https://www.youtube-nocookie.com/embed/lJloI0ugJI8?controls=0"
title="How the DWeb works under the hood"
frameborder="0"
allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
allowfullscreen
></iframe>
## General
<AccordionGroup>
<Accordion title="What Components make up the Sonr stack?">
**Network** -- We've built a global decentralized network that leverages our breakthrough identity module allowing for device based authentication, realtime content delivery, and true digital asset ownership. Users are provided the promised utility of Web3 without any lagging experience.
**Motor** -- The Sonr Motor node is an end to end client suite which provides all the features of our Network in an easily approachable SDK. Motor offers the easiest consumer onboarding experience in Web3 by stripping away seed phrases, and introducing multi-party computation for Quantum computing resistant encryption.
**Blockchain** -- The Blockchain is the perfect marriage for Sonr's global decentralized network. With Cosmos, we can quickly and easily connect to other blockchains, providing our users with the ability to build interoperable experiences. IBC is the perfect specification for cross-chain communication, and GravityBridge provides us with the perfect way to bridge to Ethereum. Sonr’s blockchain also provides developer with the peace of mind of knowing that user data is securely distributed across IPFS with a native bridge to Filecoin.
</Accordion>
<Accordion title="What’s preventing Web3 Mobile Apps from going mainstream?">
There are several factors that may prevent the widespread adoption of web3 mobile apps. Some of the main challenges and barriers to the adoption of web3 mobile apps include:
- Limited awareness and understanding of web3 and decentralized technologies among the general public
- Limited adoption of decentralized technologies and infrastructure by developers and businesses
- Limited availability of user-friendly web3 mobile apps and tools
- Limited scalability and performance of decentralized networks and applications
- Regulatory uncertainty and potential legal challenges
Overall, the adoption of web3 mobile apps is currently limited by a range of technical, market, and regulatory challenges. These challenges will need to be addressed in order for web3 mobile apps to become more widely used and adopted.
</Accordion>
<Accordion title="Will DIDs replace traditional authentication in the future?">
It is possible that DIDs (decentralized IDs) could eventually replace traditional forms of authentication, such as username and password combinations, in the future. DIDs are a key component of the decentralized identity (DID) ecosystem, which is being developed to provide individuals and organizations with control over their own digital identities and data. DIDs are designed to be secure, decentralized, and interoperable, and can be used to represent a wide range of identity-related information in a secure and decentralized way.
The use of DIDs for authentication has several potential benefits over traditional forms of authentication. For example, DIDs can provide a more secure and decentralized way to authenticate users, as they are stored on a decentralized ledger (such as a blockchain) and can be accessed and verified by anyone with the appropriate permissions. This can help to improve the security and privacy of online authentication, and can reduce the risk of identity theft and other security threats. DIDs can also be more user-friendly and convenient for users, as they can be easily accessed and managed using a variety of different devices and applications.
Overall, it is possible that DIDs could eventually replace traditional forms of authentication, but this will depend on the continued development and adoption of decentralized identity technologies and infrastructure.
</Accordion>
<Accordion title="How large is the Cosmos Ecosystem?">
The exact size of the Cosmos ecosystem is difficult to determine, as it includes a wide range of projects, applications, and stakeholders. However, the Cosmos ecosystem is generally considered to be one of the largest and most active communities in the decentralized technology space, and it continues to grow and evolve over time.
The Cosmos ecosystem is focused on building an open, interoperable, and scalable ecosystem of decentralized networks and applications. This ecosystem is based on the Cosmos SDK, a framework for building blockchain applications, and the Inter-Blockchain Communication (IBC) protocol, which allows different blockchain networks to interoperate with each other. The Cosmos ecosystem also includes a range of tools, services, and resources that are designed to support the development and adoption of decentralized technologies and applications.
</Accordion>
<Accordion title="What was Tim Berners Lee’s Original Vision for the Internet?">
Tim Berners-Lee, the inventor of the World Wide Web, has expressed a vision for the future of the internet that emphasizes decentralization, interoperability, and user control. In this vision, the internet would be a more open, transparent, and democratic platform, where users have more control over their own data and online experiences.
Berners-Lee has referred to this vision as the "POD" (Personal Online Data) model, and has described it as a way to "take back the web" from the large technology companies that currently dominate the internet landscape. In the POD model, users would be able to store their own data on personal servers or other decentralized storage systems,
and would be able to control who has access to that data. This would enable users to have more control over their own data and online experiences, and would help to reduce the concentration of power and control in the hands of a few large technology companies.
</Accordion>
</AccordionGroup>
## Developers
<AccordionGroup>
<Accordion title="Why build on Sonr?">
Sonr's decentralized, realtime network provides Web3 developers with a tool-set that to quickly deploy scalable Web3 applications, with verifiable data that can be reused and shared across all Sonr powered applications.
- **Developer Experience** -- We believe application development should be as straight forward as possible. Sonr's SDK's is an all-in-one solution for developing applications for the Sonr network. We believe in consistency and openness, as our libraries are built on open standards.
- **Composable by Design** -- Our protocols are flexible and are capable of wrapping custom protocols. These protocols are extendable and support merging, which allows for reusability and composability.
</Accordion>
<Accordion title="Does Sonr have Wallet to Wallet Messaging?">
We utilize libp2p, DID documents, and MPC to have decentralized wallet-to-wallet messaging, you can follow these steps:
1. Use the libp2p library to establish a peer-to-peer network between the two wallets. This will allow the wallets to communicate directly with each other, without going through a central server.
2. Use DID documents to identify and authenticate the users of the wallets. Each user should have a DID document that contains their public keys and other relevant information. This information can be used to verify the user's identity and to establish trust between the wallets.
3. Use multi-party computation (MPC) to generate and manage the keys that are used for encrypting and signing the messages that are sent between the wallets. MPC allows multiple parties to jointly compute a function without revealing their inputs to each other, ensuring that the keys can be generated and managed in a secure, decentralized manner.
4. Use the libp2p library to send messages between the wallets, using the keys that were generated with MPC. These messages can be encrypted to ensure privacy, and can be signed to ensure authenticity.
By following these steps, it is possible to utilize libp2p, DID documents, and MPC to create decentralized wallet-to-wallet messaging. This approach allows users to securely and privately communicate with each other, while also maintaining control over their own data and assets.
</Accordion>
</AccordionGroup>
## Token
<AccordionGroup>
<Accordion title="What is the Total Supply of Tokens?">
500M, See our Distribution [here](https://www.notion.so/Token-Supply-0578a472c3364718a8634efa8c290e4b).
</Accordion>
<Accordion title="When is the Sonr Team anticipating on going to MainNet?">
We’re gearing for a Summer 2023 Launch
</Accordion>
<Accordion title="Do Developers receive Airdrops?">
Yes! Developers can receive AirDrops for submitting proposals or participating in Sonr sponsored events.
</Accordion>
<Accordion title="Whats the price of $SNR?">
The Sonr team cannot provide an anticipated price for $SNR due to the [SEC’s rules](https://cryptolawinsider.com/security-token/) on Securities.
</Accordion>
</AccordionGroup>
docs/features.mdx
+271
View File
@@ -0,0 +1,271 @@
---
title: Features
description: The peer-to-peer identity and asset management system that makes Web3 as easy as Web2 through DID documents, WebAuthn, and IPFS—providing users with secure, portable decentralized identity
icon: "puzzle"
---
# Introduction to Sonr
<Note title="Scope">
This document introduces Sonr's blockchain architecture, core components, and
integration patterns. It covers identity management, authentication, data
sovereignty, and cross-chain operations. This document does not cover
implementation details or code examples—see the Quick Start Guide for hands-on
tutorials.
</Note>
<Note title="Audience">
**Developers** building Web3 applications who want simple integration
patterns. **Validators** interested in securing a next-generation blockchain
network. **Users** seeking sovereign digital identity solutions.
Prerequisites: Basic understanding of web development (HTML/JavaScript) for
developers; blockchain consensus for validators.
</Note>
## Summary
Sonr is a Cosmos SDK blockchain that simplifies Web3 through **Decentralized Identity (DIDs)**, **passwordless authentication (WebAuthn)**, and **user-controlled agents (Vaults)**. Developers integrate crypto features using standard web technologies. Validators secure a network bridging Web2 and Web3. Users gain digital sovereignty without complexity.
## What is Sonr?
Sonr transforms blockchain interaction through four innovations:
1. **W3C-compliant DIDs** replace wallet addresses
2. **WebAuthn** eliminates seed phrases
3. **Personal Vaults** automate blockchain operations
4. **UCAN permissions** prevent unlimited approvals
These components create a system where users onboard in 30 seconds using biometrics, developers add crypto features with HTML forms, and validators earn rewards securing digital sovereignty.
## Why Sonr Matters
### Current Problems
Traditional Web3 forces users to:
- Manage 24-word seed phrases
- Install browser extensions
- Understand gas fees
- Navigate multiple wallets
One mistake loses everything.
### Sonr's Solution
Sonr provides:
- **30-second onboarding** with Face ID or fingerprint
- **No seed phrases** through WebAuthn security
- **No gas fees** for account creation
- **Universal compatibility** across all devices
- **Automatic recovery** via social and biometric methods
## Core Architecture
<CardGroup>
<Card title="Decentralized Identity (DID)" href="/blockchain/modules/did/">
W3C-compliant identity system using WebAuthn for passwordless authentication
</Card>
<Card title="Decentralized Web Nodes (DWN)" href="/blockchain/modules/dwn/">
Personal Vaults acting as user-controlled agents for blockchain interactions
</Card>
<Card title="UCAN Authorization" href="/blockchain/modules/svc/ucan">
Capability-based permissions replacing dangerous unlimited approve patterns
</Card>
<Card title="Service Registry" href="/blockchain/modules/svc/">
Stake-based trust system for service discovery and DNS verification
</Card>
</CardGroup>
## For Developers
### Integration Benefits
Sonr enables crypto features without blockchain knowledge:
- **Use existing skills**: HTML, CSS, JavaScript
- **Zero dependencies**: No SDKs or wallet libraries
- **Progressive enhancement**: Start simple, add features
- **Enterprise ready**: Integrates with existing auth systems
### Simple Payment Example
Transform any HTML form into a crypto payment interface:
```html
<form hx-post="/api/sonr/payment" hx-target="#result">
<input type="email" name="recipient" placeholder="alice@sonr.id" />
<input type="number" name="amount" placeholder="25.00" />
<select name="currency">
<option value="USDC">USDC</option>
<option value="ATOM">ATOM</option>
</select>
<button type="submit">Send Payment</button>
</form>
```
Users approve with biometrics. Vaults handle transactions. No wallet connections required.
### Developer Resources
<CardGroup>
<Card title="Browser Integration" href="/quickstart/browser">
Browser integration patterns and WebAuthn examples
</Card>
<Card title="Wallet Architecture" href="/highway/">
Highway system powering user sovereignty
</Card>
<Card title="Payment Systems" href="/highway/wallets/sending-payments">
Payment integration and transaction management
</Card>
<Card title="Service Registry" href="/blockchain/modules/svc/">
DNS verification and stake-based trust
</Card>
</CardGroup>
## For Validators
### Network Components
Validators secure four critical systems:
<CardGroup>
<Card title="Blockchain Core" href="/blockchain/">
Cosmos SDK with IBC for cross-chain operations
</Card>
<Card title="Network Architecture" href="/blockchain/network">
Network topology and consensus mechanisms
</Card>
<Card title="Highway Proxy" href="/highway/">
HTTP bridge supporting WebAuthn authentication
</Card>
<Card title="Token Economics" href="/blockchain/token/">
Tokenomics and staking mechanisms
</Card>
</CardGroup>
### Validator Operations
Validators perform five key functions:
1. **Validate identities**: Process DID operations and WebAuthn credentials
2. **Execute Vaults**: Run capability delegations and revocations
3. **Bridge chains**: Process IBC and InterchainAccount transactions
4. **Verify services**: Validate DNS ownership and registrations
5. **Coordinate MPC**: Participate in multi-party key management
### Economic Incentives
- **Block rewards**: Earn from transaction fees and inflation
- **Service fees**: Share revenue from registrations
- **MEV protection**: Built-in maximal extractable value prevention
- **Sustainable model**: Long-term network health design
## Key Concepts
### Identity Management
<CardGroup>
<Card title="Identity System" href="/blockchain/modules/did/">
W3C DIDs with WebAuthn for digital sovereignty
</Card>
<Card title="DID Module" href="/blockchain/modules/did/">
Blockchain implementation of identity management
</Card>
</CardGroup>
### Data Sovereignty
<CardGroup>
<Card title="DWN Module" href="/blockchain/modules/dwn/">
Personal Vaults for user-controlled data and agents
</Card>
<Card title="Network Architecture" href="/blockchain/network">
Network architecture and cross-chain features
</Card>
</CardGroup>
### Authorization System
<CardGroup>
<Card title="UCAN Module" href="/blockchain/modules/svc/ucan">
Capability-based permissions for secure delegation
</Card>
<Card title="Service Module" href="/blockchain/modules/svc/">
Registration, verification, and trust management
</Card>
</CardGroup>
### Cross-Chain Features
<CardGroup>
<Card title="Network Protocol" href="/blockchain/network">
Bridgeless transactions via InterchainAccounts
</Card>
<Card title="Payment Handler" href="/highway/wallets/sending-payments">
W3C API for seamless crypto payments
</Card>
</CardGroup>
## Getting Started
### Developers
Build Web3 applications without blockchain complexity:
<CardGroup>
<Card title="Quick Start" href="/quickstart/">
Create your first Sonr application in 10 minutes
</Card>
<Card title="Browser Integration" href="/quickstart/browser">
Real-world browser integration examples
</Card>
<Card title="CLI Tools" href="/quickstart/cli">
Command line tools and utilities
</Card>
</CardGroup>
### Validators
Secure the future of digital sovereignty:
<CardGroup>
<Card title="Node Setup" href="/quickstart/validators">
Complete validator installation guide
</Card>
<Card title="Token Economics" href="/blockchain/token/">
Token distribution, staking, and governance
</Card>
<Card title="Security" href="/reference/security/">
Security best practices and compliance
</Card>
</CardGroup>
### Users
Experience true digital ownership:
<CardGroup>
<Card title="Create Identity" href="/blockchain/modules/did/onboarding">
30-second setup with biometric authentication
</Card>
<Card title="Use Your Vault" href="/blockchain/modules/dwn/">
Master your personal Web3 agent
</Card>
<Card title="Security Guide" href="/reference/security/">
Privacy and sovereignty protection
</Card>
</CardGroup>
## Next Steps
<Note title="Ready to Build?" type="success">
**Developers**: Start with the [Quick Start Guide](/quickstart/) to build your first Sonr application.
**Validators**: Follow the [Node Setup Guide](/quickstart/validators) to join the network.
**Users**: [Create your identity](/blockchain/modules/did/onboarding) in under 30 seconds.
</Note>
Explore the concepts above or dive into specific topics using the navigation menu. Join us in building the sovereign internet where identity belongs to individuals, not platforms.
docs/getting-started/developers.mdx
View File
docs/getting-started/users.mdx
View File
docs/getting-started/validators.mdx
View File
docs/guides/authorize-clients.mdx
+221
View File
@@ -0,0 +1,221 @@
---
title: "Authorization with UCAN"
description: "Comprehensive guide to creating, validating, and managing User-Controlled Authorization Network (UCAN) tokens"
sidebarTitle: Client Authorization
icon: "badge-check"
---
# UCAN Token Operations
User-Controlled Authorization Networks (UCAN) provide a decentralized authorization mechanism that enables flexible, portable, and secure token-based access control.
## Overview
UCAN tokens are JWT-based authorization tokens that allow:
- Decentralized identity verification
- Granular access control
- Delegatable permissions
- Cryptographic proof of authorization
## Token Structure
A UCAN token consists of:
- Issuer DID
- Audience DID
- Capabilities (Attenuations)
- Proofs (Optional parent tokens)
- Time-based constraints
## Creating Origin Tokens
An origin token is the first token in a delegation chain:
```go
type NewOriginTokenRequest struct {
AudienceDID string // Target DID
Attenuations []map[string]any // Token restrictions
Facts []string // Additional claims
NotBefore int64 // Token activation time
ExpiresAt int64 // Token expiration time
}
// Example origin token creation
originToken := NewOriginTokenRequest{
AudienceDID: "did:sonr:example-recipient",
Attenuations: []{
{
"capability": "read",
"resource": "/storage/documents"
}
},
Facts: ["authenticated_user"],
NotBefore: time.Now().Unix(),
ExpiresAt: time.Now().Add(24 * time.Hour).Unix()
}
```
## Creating Attenuated Tokens
Attenuated tokens derive from existing tokens, further restricting capabilities:
```go
type NewAttenuatedTokenRequest struct {
ParentToken string // Previous token
AudienceDID string // New token recipient
Attenuations []map[string]any // Further restrictions
Facts []string // Additional claims
NotBefore int64 // Token activation time
ExpiresAt int64 // Token expiration time
}
// Example attenuated token
attenuatedToken := NewAttenuatedTokenRequest{
ParentToken: originTokenString,
AudienceDID: "did:sonr:delegated-user",
Attenuations: []{
{
"capability": "read",
"resource": "/storage/documents/public"
}
}
}
```
## Token Validation Workflow
```go
func ValidateUCANToken(token string) (bool, error) {
// 1. Parse the token
parsedToken, err := jwt.Parse(token, keyFunc)
if err != nil {
return false, err
}
// 2. Verify issuer DID
issuerDID := parsedToken.Claims["iss"]
if !isDIDValid(issuerDID) {
return false, errors.New("invalid issuer DID")
}
// 3. Check audience
audienceDID := parsedToken.Claims["aud"]
if !isCurrentUserAudience(audienceDID) {
return false, errors.New("token not intended for this audience")
}
// 4. Validate time constraints
if isTokenExpired(parsedToken) {
return false, errors.New("token has expired")
}
// 5. Check capabilities
capabilities := parsedToken.Claims["att"]
if !validateCapabilities(capabilities) {
return false, errors.New("insufficient capabilities")
}
// 6. Verify proofs (if present)
proofs := parsedToken.Claims["prf"]
if !validateProofChain(proofs) {
return false, errors.New("invalid proof chain")
}
return true, nil
}
```
## Capability Patterns
### Read Capabilities
```json
{
"capability": "read",
"resource": "/storage/documents",
"conditions": {
"max_size": "10MB",
"allowed_types": ["pdf", "txt"]
}
}
```
### Write Capabilities
```json
{
"capability": "write",
"resource": "/storage/documents",
"conditions": {
"max_files": 5,
"max_file_size": "50MB"
}
}
```
## Practical Examples
### Decentralized File Sharing
```go
// Create an origin token for file access
originToken := NewOriginTokenRequest{
AudienceDID: "did:sonr:collaborator",
Attenuations: []{
{
"capability": "read",
"resource": "/project/design-docs"
},
{
"capability": "write",
"resource": "/project/design-docs/comments"
}
},
ExpiresAt: time.Now().Add(30 * 24 * time.Hour).Unix()
}
// Later, create a more restricted token
limitedToken := NewAttenuatedTokenRequest{
ParentToken: originTokenString,
AudienceDID: "did:sonr:junior-designer",
Attenuations: []{
{
"capability": "read",
"resource": "/project/design-docs/public"
}
}
}
```
## Security Considerations
- Use the shortest possible token lifetime
- Implement granular capabilities
- Validate all tokens before use
- Rotate keys regularly
- Log and monitor token usage
## Performance Optimization
- Cache validated tokens
- Use efficient JWT parsing
- Implement token revocation lists
## Advanced Topics
- [DID Module](/blockchain/modules/did/)
- [DWN Architecture](/blockchain/modules/dwn/architecture)
- [Service Registry](/blockchain/modules/svc/)
## Error Handling
```go
type UCANError struct {
Code string
Message string
Details map[string]any
}
```
By leveraging UCAN tokens, you can create a flexible, secure, and decentralized authorization system that puts users in control of their access.
docs/guides/broadcast-transactions.mdx
+411
View File
@@ -0,0 +1,411 @@
---
title: Transactions
description: Transaction types, fee structures, and token mechanics for SNR within the Sonr network
sidebarTitle: Broadcast Transactions
icon: "send"
---
## Overview
SNR token transactions power the revolutionary Sonr ecosystem, enabling gasless onboarding, stake-based service registration, and UCAN-authorized operations. The unique architecture allows for both traditional fee-based transactions and innovative gasless user experiences.
<Note>
Sonr features both traditional fee-based transactions and revolutionary
gasless operations like vault claiming, enabling zero-barrier user onboarding
while maintaining network security through economic incentives.
</Note>
## Transaction Types
### Basic Transfers
The foundation of the SNR economy consists of peer-to-peer token transfers:
<CardGroup>
<Card title="Simple Transfers">
Direct SNR transfers between addresses with minimal gas fees
</Card>
<Card title="Multi-send">
Batch transfers to multiple recipients in a single transaction
</Card>
<Card title="Scheduled Transfers">
Time-locked transfers with vesting or release conditions
</Card>
</CardGroup>
### Module-Specific Transactions
Each Sonr core module enables specialized transaction types with specific SNR token requirements:
#### Service Module (x/svc) Transactions
- **MsgRegisterService**: Register a new service with TLD domain verification and capability requests
- **MsgUpdateService**: Update service metadata or request additional permissions
- **DNS Verification**: Simple DNS TXT record verification for domain ownership
- **Stake Requirements**: Services must stake SNR tokens based on requested capabilities
#### DWN Module (x/dwn) Transactions
- **MsgClaimVault**: **Gasless** transaction for claiming user vaults during onboarding
- **Vault Configuration Updates**: Paid transactions for advanced vault settings and WASM runtime upgrades
- **Cross-Chain Operations**: SNR fees for multi-chain vault management and bridging
- **MPC Operations**: Transaction fees for multi-party computation within secure enclaves
#### UCAN Module (x/ucan) Transactions
- **MsgIssueRootCapability**: Request MPC threshold signing for root capability tokens
- **MsgSubmitThresholdShare**: Validators submit MPC shares for capability creation
- **MsgRevokeCapability**: Revoke previously issued capability tokens on-chain
- **Delegation Chain Processing**: Computational fees for validating complex authorization chains
#### DID Module (x/did) Transactions
- **DID Registration**: Fees for creating new decentralized identifiers
- **MsgLinkAuthentication**: Add WebAuthn credentials or other authentication methods
- **MsgLinkAssertion**: Link identity claims and verifications to DIDs
- **MsgExecuteTx**: Execute UCAN-authorized transactions on behalf of DIDs
## Fee Structure
### Dual Fee Model
Sonr implements a revolutionary dual fee model supporting both traditional gas fees and gasless operations:
```math
\text{Fee} = \begin{cases}
0 & \text{for gasless operations (vault claiming)} \\
\text{Base Cost} + (\text{Gas Used} \times \text{Gas Price}) & \text{for standard transactions}
\end{cases}
```
<Warning>
While basic vault claiming is gasless, advanced operations like service
registration, MPC signing, and cross-chain transactions require SNR tokens for
network security and spam prevention.
</Warning>
### Fee Components
<CardGroup>
<Card title="MPC Computation">
Multi-party computation costs for threshold signing and capability issuance
</Card>
<Card title="Stake-Based Security">
Service registration fees that are burned or sent to community pool
</Card>
<Card title="Cross-Chain Operations">
IBC and InterchainAccount transaction costs for bridgeless operations
</Card>
<Card title="Identity Operations">
DID registration, authentication linking, and credential management
</Card>
</CardGroup>
### Economic Mechanisms
The network implements sophisticated economic mechanisms:
1. **Gasless Subsidies**: Network subsidizes vault claiming for zero-barrier onboarding
2. **Stake-Based Pricing**: Service registration costs scale with capability requests
3. **MPC Rewards**: Validators earn additional fees for threshold signing participation
4. **Deflationary Pressure**: Service registration fees are burned, reducing total supply
## Transaction Lifecycle
### Gasless Vault Claiming Flow
```mermaid
graph LR
A[WebAuthn Creation] --> B[Client-Side Vault Config]
B --> C[Submit MsgClaimVault]
C --> D[Network Subsidy Check]
D --> E[Gasless Execution]
E --> F[Vault Active]
```
### Service Registration Flow
```mermaid
graph LR
A[DNS Verification] --> B[Stake Calculation]
B --> C[MsgRegisterService]
C --> D[Capability Request]
D --> E[MPC Signing]
E --> F[Root UCAN Issued]
```
### UCAN Authorization Flow
```mermaid
graph LR
A[Service Request] --> B[Capability Check]
B --> C[User Approval]
C --> D[UCAN Creation]
D --> E[Delegation Chain]
E --> F[Authorized Execution]
```
### Standard Transaction Processing
1. **UCAN Validation**: Check authorization tokens and delegation chains
2. **Module Routing**: Route to appropriate module (svc, dwn, ucan, did)
3. **MPC Coordination**: Multi-party computation for sensitive operations
4. **State Updates**: Update module-specific state and emit events
5. **Fee Distribution**: Distribute fees to validators, burn pool, and treasury
## Advanced Features
### UCAN-Powered Automation
Enable sophisticated authorization patterns:
<CardGroup>
<Card title="Capability Delegation">
Services receive granular, time-limited permissions from users
</Card>
<Card title="Agent Execution">
Motr Vaults execute pre-authorized actions without user intervention
</Card>
<Card title="Subscription Automation">
Recurring payments and service interactions through UCAN tokens
</Card>
</CardGroup>
### Multi-Party Computation Integration
Leverage MPC for secure operations:
- **Threshold Signing**: Validators collaborate to issue root capabilities
- **Key Sharding**: No single point of failure for vault key management
- **Secure Enclaves**: WASM-based computation with hardware security
- **Privacy Preservation**: Zero-knowledge proofs for sensitive operations
### Cross-Module Interactions
Transactions can interact with multiple Sonr modules in powerful combinations:
```typescript
// Example: Complete user onboarding with service registration
const tx = {
messages: [
// DID Module: Create decentralized identity
{
type: "did/MsgCreateDID",
creator: "sonr1abc...",
document: didDocument,
webauthnCredential: credential,
},
// DWN Module: Claim gasless vault
{
type: "dwn/MsgClaimVault",
creator: "did:sonr:alice123",
vaultConfig: vaultCID,
mpcThreshold: 3,
},
// Service Module: Register domain service
{
type: "svc/MsgRegisterService",
creator: "did:sonr:alice123",
domain: "alice-app.com",
capabilities: ["dwn:read", "dwn:write"],
stakeAmount: "5000usnr",
},
// UCAN Module: Request root capability
{
type: "ucan/MsgIssueRootCapability",
issuer: "did:sonr:alice123",
audience: "alice-app.com",
capabilities: ["service:register"],
},
],
fee: {
amount: [{ denom: "usnr", amount: "5000" }], // Only service registration fee
gasLimit: "500000",
},
memo: "Complete onboarding: Identity + Vault + Service + Capabilities",
};
// Example: Cross-chain payment automation
const paymentTx = {
messages: [
// UCAN: Validate payment authority
{
type: "ucan/MsgValidateCapability",
token: ucanPaymentToken,
requestedAction: "payment:send",
},
// DID: Execute authorized transaction
{
type: "did/MsgExecuteTx",
signer: "did:sonr:alice123",
targetChain: "osmosis-1",
transaction: swapTransaction,
authorization: ucanToken,
},
],
};
```
## Performance Optimization
### Module-Specific Batching
Optimize transactions by batching within module boundaries:
1. **DWN Operations**: Batch vault updates and data operations
2. **Service Operations**: Group domain verifications and capability requests
3. **UCAN Processing**: Batch capability validations and delegation chains
4. **Cross-Chain Coordination**: Bundle InterchainAccount operations
### Gasless Operation Prioritization
Sonr prioritizes gasless operations to enhance user experience:
<Check>
Gasless vault claiming is prioritized by validators to enable zero-friction
onboarding. Service registration and MPC operations use dynamic pricing based
on network demand and stake requirements.
</Check>
### MPC Coordination Efficiency
Multi-party computation operations are optimized for performance:
```typescript
// MPC threshold signing optimization
interface MPCOptimization {
parallelShares: boolean; // Generate shares in parallel
precomputedCommitments: boolean; // Cache commitments
batchSigning: boolean; // Sign multiple capabilities together
networkSharding: boolean; // Distribute computation load
}
```
## Security Considerations
### Module-Specific Security
- **DID Security**: WebAuthn hardware-backed authentication prevents identity theft
- **UCAN Validation**: Cryptographic proof chains ensure capability authenticity
- **Vault Isolation**: MPC key sharding prevents single points of failure
- **Service Reputation**: Stake-based trust system deters malicious actors
### Zero-Knowledge Privacy
Sonr implements privacy-preserving transaction patterns:
```typescript
// Privacy-preserving operations
interface PrivacyFeatures {
zkProofs: {
ageVerification: boolean; // Prove age without revealing birthdate
balanceProofs: boolean; // Prove sufficient funds without amounts
reputationProofs: boolean; // Prove service quality without data
};
selectiveDisclosure: {
didDocuments: boolean; // Share only necessary identity claims
vaultData: boolean; // Controlled data access permissions
paymentHistory: boolean; // Private transaction records
};
}
```
### Best Practices for Sonr Transactions
1. **UCAN Validation**: Always verify capability tokens before execution
2. **MPC Coordination**: Ensure threshold requirements are met
3. **Gasless Limits**: Monitor gasless operation quotas and fallbacks
4. **Cross-Chain Safety**: Validate IBC channel security and timeouts
## Fee Distribution
SNR transaction fees are distributed to align network incentives:
<CardGroup>
<Card title="Validators (35%)">
Block proposers and MPC threshold signers receive primary rewards
</Card>
<Card title="Burn Pool (25%)">
Service registration fees burned for deflationary pressure
</Card>
<Card title="Community Treasury (25%)">
Development and ecosystem growth funds
</Card>
<Card title="Gasless Subsidy (10%)">
Funds vault claiming and onboarding operations
</Card>
<Card title="IBC Relayers (5%)">
Cross-chain message delivery and InterchainAccount operations
</Card>
</CardGroup>
### Module-Specific Fee Sources
```typescript
// Fee sources by module
interface ModuleFees {
svc: {
domainRegistration: "25% to burn, 75% to validators";
capabilityRequests: "Deposit-based, refundable on completion";
stakeSlashing: "100% to community treasury";
};
dwn: {
vaultClaiming: "Gasless (subsidized by treasury)";
storageOperations: "Standard gas fees";
mpcOperations: "Premium fees for computation";
};
ucan: {
rootCapabilityIssuance: "MPC coordination fees";
delegationValidation: "Minimal computational costs";
revocations: "Standard gas fees";
};
did: {
didRegistration: "One-time identity creation fee";
credentialLinking: "WebAuthn integration costs";
crossChainExecution: "IBC and InterchainAccount fees";
};
}
```
## Future Enhancements
### Revolutionary Capabilities in Development
- **AI-Powered Automation**: Natural language transaction commands through Motr Vault agents
- **Predictive Authorization**: Pre-approve expected transactions based on user patterns
- **W3C Payment Handler**: Native browser integration for seamless Web2/Web3 payments
- **Subscription Automation**: Recurring payments through UCAN capability delegation
- **Privacy-First Operations**: Full zero-knowledge transaction processing
- **Hardware Enclave Integration**: Dedicated Sonr hardware for enhanced security
- **Cross-Chain DeFi**: Seamless DeFi operations across all supported chains
- **Social Recovery Networks**: Trustless account recovery through guardian systems
### Standards-Based Interoperability
Building on open standards for maximum compatibility:
```typescript
// Future standards integration
interface FutureStandards {
w3cCompliance: {
paymentHandlerAPI: "Native browser payment integration";
webauthnLevel3: "Enhanced biometric authentication";
didCore2: "Next-generation identity standards";
};
crossChainStandards: {
ibcV2: "Enhanced cross-chain capabilities";
cosmwasmCompatibility: "Universal smart contract execution";
evmIntegration: "Ethereum Virtual Machine support";
};
privacyStandards: {
zkStarks: "Scalable zero-knowledge proofs";
selectiveDisclosure: "W3C verifiable credentials";
confidentialComputing: "Hardware-backed privacy";
};
}
```
docs/guides/configure-local-node.mdx
+48
View File
@@ -0,0 +1,48 @@
---
title: "Configuring a Validator Node"
sidebarTitle: "Command Line"
description: "Setup a validator node on the Sonar Network in your local environment"
icon: "terminal"
---
**1. Initialize a blockchain node**
```sh
sonrd init localnet
```
**2. Generate account keys**
```sh
sonrd keys add test-validator
```
**3. Add the account to the genesis file**
```sh
sonrd add-genesis-account $(sonrd keys show test-validator -a) 1000000000000000000000000000stake,1000000000000000000000000000snr
```
**4. Generate a genesis transaction**
```sh
sonrd gentx test-validator 1000000000000000000000000000stake --chain-id localnet
```
**5. Collect genesis transactions**
```sh
sonrd collect-gentxs
```
**6. Validate the genesis file**
```sh
sonrd validate-genesis
```
**7. Start the blockchain node**
```sh
sonrd start
```
docs/guides/deployment.mdx
+8
View File
@@ -0,0 +1,8 @@
---
title: Production Network Deployment
description: Complete guide for becoming a Sonr blockchain validator - from setup to operations
icon: "ship"
sidebarTitle: Deploy Network & Services
---
docs/guides/development.mdx
+8
View File
@@ -0,0 +1,8 @@
---
title: Local Development Setup
description: Complete guide for becoming a Sonr blockchain validator - from setup to operations
icon: "code"
sidebarTitle: Setup Your Environment
---
docs/guides/establish-connection.mdx
+173
View File
@@ -0,0 +1,173 @@
---
title: Requesting Permissions
description: A guide to setting up and managing wallet connections with the Sonr decentralized identity system
icon: "shield-check"
---
Sonr provides a seamless and secure way for users to connect their wallets to decentralized applications. This guide covers the different methods for establishing and managing wallet connections, from simple browser-based interactions to backend service integrations.
## The Sonr Connection Model
Unlike traditional Web3 wallets that require browser extensions, Sonr uses a combination of WebAuthn and Decentralized Identifiers (DIDs) to create a secure, passwordless connection experience.
<CardGroup>
<Card title="User-Centric" href="/blockchain/modules/did/">
Users control their identity and grant permissions to applications, not the
other way around.
</Card>
<Card title="Passwordless" href="/blockchain/modules/did/">
WebAuthn enables biometric and security key authentication, eliminating the
need for seed phrases.
</Card>
<Card title="Multi-Device" href="/blockchain/modules/dwn/">
Users can securely access their Vault from any device with a modern web
browser.
</Card>
</CardGroup>
## Connecting in the Browser
For web applications, the Sonr SDK provides a simple way to initiate a wallet connection.
<Steps>
<Step>
### 1. Initialize the SDK
First, initialize the Sonr SDK in your application. For this example, we'll use the CDN version.
```html
<script type="module">
import { Sonr } from "https://cdn.jsdelivr.net/npm/@sonr/sdk";
const sonr = new Sonr({ httpUrl: "http://localhost:1317" });
</script>
```
</Step>
<Step>
### 2. Request Authentication
Use the `sonr.authenticate()` method to prompt the user to connect their wallet. This will trigger the browser's WebAuthn flow.
```javascript
async function connectWallet() {
try {
const session = await sonr.authenticate();
console.log("Wallet connected!", session);
// You now have a secure session with the user's Vault
} catch (error) {
console.error("Failed to connect wallet:", error);
}
}
```
</Step>
<Step>
### 3. Handle the Session
The `session` object returned from `authenticate()` contains the user's DID and a UCAN token with the requested permissions. You can use this session to interact with the user's Vault.
```javascript
// Example: Get the user's balance
const balance = await session.vault.getAccountBalance();
console.log("User balance:", balance);
```
</Step>
</Steps>
## Backend Wallet Connections
For backend services, you can use the Sonr SDK to interact with user Vaults on behalf of your application.
<Steps>
<Step>
### 1. Service Registration
Your backend service must be registered on the Sonr network. This provides your service with its own DID and allows it to request permissions from users.
{/* Service registration documentation is referenced but not yet available in the docs structure */}
</Step>
<Step>
### 2. Requesting Permissions
Your service can request permissions from users by generating a UCAN request. This is typically done through a user-facing application.
```typescript
// Example: Requesting permission to read a user's profile
const ucanRequest = await sonr.ucan.request({
audience: "did:sonr:your-service-did",
resource: `dwn://user-did/profile/read`,
});
// Present this request to the user to be signed by their Vault
```
</Step>
<Step>
### 3. Using Delegated Capabilities
Once a user has approved your request, you will receive a delegated UCAN token. You can use this token to perform actions on the user's behalf.
```go
// Example: Using a delegated UCAN in a Go backend
import "github.com/sonr-io/sonr/x/sonr/pkgs/sdk"
func GetUserProfile(userDID string, delegatedUcan string) (*Profile, error) {
sonr, _ := sdk.NewSonr(rpcEndpoint, "")
// Use the delegated UCAN to access the user's profile
profile, err := sonr.GetUserProfile(userDID, delegatedUcan)
if err != nil {
return nil, err
}
return profile, nil
}
```
</Step>
</Steps>
## Managing Connections
### Checking Connection Status
You can check the current connection status at any time:
```javascript
const session = await sonr.getSession();
if (session) {
console.log("User is connected:", session.did);
} else {
console.log("User is not connected.");
}
```
### Disconnecting
To disconnect a wallet, simply clear the session from your application's state:
```javascript
await sonr.logout();
console.log("User has been disconnected.");
```
This will revoke the current session's UCAN token, but it will not remove any permissions the user has granted to your service.
## Security Considerations
- **UCAN Scopes**: Always request the minimum permissions necessary for your application to function.
- **Token Storage**: Securely store delegated UCAN tokens on your backend. Never expose them on the client-side.
- **Revocation**: Your application should handle UCAN revocations gracefully.
## Next Steps
- [Sending Payments](/highway/wallets/sending-payments)
- [Understanding UCANs](/blockchain/modules/svc/ucan)
- [Explore DWN Architecture](/blockchain/modules/dwn/)
docs/guides/install.mdx
+254
View File
@@ -0,0 +1,254 @@
---
title: Build with Sonr
description: The peer-to-peer identity and asset management system that makes Web3 as easy as Web2 through DID documents, WebAuthn, and IPFS—providing users with secure, portable decentralized identity
sidebarTitle: "Installation"
icon: "download"
---
## Summary
Sonr is a Cosmos SDK blockchain that simplifies Web3 through **Decentralized Identity (DIDs)**, **passwordless authentication (WebAuthn)**, and **user-controlled agents (Vaults)**. Developers integrate crypto features using standard web technologies. Validators secure a network bridging Web2 and Web3. Users gain digital sovereignty without complexity.
## What is Sonr?
Sonr transforms blockchain interaction through four innovations:
1. **W3C-compliant DIDs** replace wallet addresses
2. **WebAuthn** eliminates seed phrases
3. **Personal Vaults** automate blockchain operations
4. **UCAN permissions** prevent unlimited approvals
These components create a system where users onboard in 30 seconds using biometrics, developers add crypto features with HTML forms, and validators earn rewards securing digital sovereignty.
## Why Sonr Matters
### Current Problems
Traditional Web3 forces users to:
- Manage 24-word seed phrases
- Install browser extensions
- Understand gas fees
- Navigate multiple wallets
One mistake loses everything.
### Sonr's Solution
Sonr provides:
- **30-second onboarding** with Face ID or fingerprint
- **No seed phrases** through WebAuthn security
- **No gas fees** for account creation
- **Universal compatibility** across all devices
- **Automatic recovery** via social and biometric methods
## Core Architecture
<CardGroup>
<Card title="Decentralized Identity (DID)" href="/blockchain/modules/did/">
W3C-compliant identity system using WebAuthn for passwordless authentication
</Card>
<Card title="Decentralized Web Nodes (DWN)" href="/blockchain/modules/dwn/">
Personal Vaults acting as user-controlled agents for blockchain interactions
</Card>
<Card title="UCAN Authorization" href="/blockchain/modules/svc/ucan">
Capability-based permissions replacing dangerous unlimited approve patterns
</Card>
<Card title="Service Registry" href="/blockchain/modules/svc/">
Stake-based trust system for service discovery and DNS verification
</Card>
</CardGroup>
## For Developers
### Integration Benefits
Sonr enables crypto features without blockchain knowledge:
- **Use existing skills**: HTML, CSS, JavaScript
- **Zero dependencies**: No SDKs or wallet libraries
- **Progressive enhancement**: Start simple, add features
- **Enterprise ready**: Integrates with existing auth systems
### Simple Payment Example
Transform any HTML form into a crypto payment interface:
```html
<form hx-post="/api/sonr/payment" hx-target="#result">
<input type="email" name="recipient" placeholder="alice@sonr.id" />
<input type="number" name="amount" placeholder="25.00" />
<select name="currency">
<option value="USDC">USDC</option>
<option value="ATOM">ATOM</option>
</select>
<button type="submit">Send Payment</button>
</form>
```
Users approve with biometrics. Vaults handle transactions. No wallet connections required.
### Developer Resources
<CardGroup>
<Card title="Browser Integration" href="/quickstart/browser">
Web browser integration patterns and examples
</Card>
<Card title="Highway Wallet" href="/highway/">
Highway system powering user sovereignty
</Card>
<Card title="Payment Integration" href="/highway/wallets/sending-payments">
Payment integration guide
</Card>
<Card title="Blockchain Modules" href="/blockchain/">
Core blockchain modules and architecture
</Card>
</CardGroup>
## For Validators
### Network Components
Validators secure four critical systems:
<CardGroup>
<Card title="Blockchain Core" href="/blockchain/">
Cosmos SDK with IBC for cross-chain operations
</Card>
<Card title="Token Economics" href="/blockchain/token/">
Tokenomics, staking, and governance
</Card>
<Card title="Highway Proxy" href="/highway/">
HTTP bridge supporting WebAuthn authentication
</Card>
<Card title="Validator Setup" href="/quickstart/validators">
Validator node setup and operations
</Card>
</CardGroup>
### Validator Operations
Validators perform five key functions:
1. **Validate identities**: Process DID operations and WebAuthn credentials
2. **Execute Vaults**: Run capability delegations and revocations
3. **Bridge chains**: Process IBC and InterchainAccount transactions
4. **Verify services**: Validate DNS ownership and registrations
5. **Coordinate MPC**: Participate in multi-party key management
### Economic Incentives
- **Block rewards**: Earn from transaction fees and inflation
- **Service fees**: Share revenue from registrations
- **MEV protection**: Built-in maximal extractable value prevention
- **Sustainable model**: Long-term network health design
## Key Concepts
### Identity Management
<CardGroup>
<Card title="Identity System" href="/blockchain/modules/did/">
W3C DIDs with WebAuthn for digital sovereignty
</Card>
<Card title="DID Module" href="/blockchain/modules/did/">
Blockchain implementation of identity management
</Card>
</CardGroup>
### Data Sovereignty
<CardGroup>
<Card title="DWN Module" href="/blockchain/modules/dwn/">
Personal Vaults for user-controlled data and agents
</Card>
<Card title="Blockchain Network" href="/blockchain/network">
Network architecture and specifications
</Card>
</CardGroup>
### Authorization System
<CardGroup>
<Card title="UCAN Module" href="/blockchain/modules/svc/ucan">
Capability-based permissions for secure delegation
</Card>
<Card title="Service Module" href="/blockchain/modules/svc/">
Registration, verification, and trust management
</Card>
</CardGroup>
### Cross-Chain Features
<CardGroup>
<Card title="Blockchain Network" href="/blockchain/network">
Network architecture and cross-chain features
</Card>
<Card title="Payment Handler" href="/highway/wallets/sending-payments">
W3C API for seamless crypto payments
</Card>
</CardGroup>
## Getting Started
### Developers
Build Web3 applications without blockchain complexity:
<CardGroup>
<Card title="Quick Start" href="/quickstart/">
Create your first Sonr application in 10 minutes
</Card>
<Card title="Browser Integration" href="/quickstart/browser">
Real-world integration patterns for web applications
</Card>
<Card title="CLI Tools" href="/quickstart/cli">
Command line tools and utilities
</Card>
</CardGroup>
### Validators
Secure the future of digital sovereignty:
<CardGroup>
<Card title="Node Setup" href="/quickstart/validators">
Complete validator installation guide
</Card>
<Card title="Token Economics" href="/blockchain/token/">
Token distribution, staking, and governance
</Card>
<Card title="Security" href="/reference/security/">
Security practices and compliance
</Card>
</CardGroup>
### Users
Experience true digital ownership:
<CardGroup>
<Card title="Create Identity" href="/blockchain/modules/did/onboarding">
30-second setup with biometric authentication
</Card>
<Card title="Use Your Vault" href="/blockchain/modules/dwn/">
Master your personal Web3 agent
</Card>
<Card title="Security Guide" href="/reference/security/">
Privacy and sovereignty protection
</Card>
</CardGroup>
## Next Steps
<Note title="Ready to Build?" type="success">
**Developers**: Start with the [Quick Start Guide](/quickstart/) to build your first Sonr application.
**Validators**: Follow the [Node Setup Guide](/quickstart/validators) to join the network.
**Users**: [Create your identity](/blockchain/modules/did/onboarding) in under 30 seconds.
</Note>
Explore the concepts above or dive into specific topics using the navigation menu. Join us in building the sovereign internet where identity belongs to individuals, not platforms.
docs/guides/issue-payments.mdx
+158
View File
@@ -0,0 +1,158 @@
---
title: Sending Payments
description: A guide for sending payments and transactions on the Sonr blockchain network
icon: "credit-card"
---
Sending payments on the Sonr network is designed to be simple and secure, whether you are building a user-facing application or a backend service. This guide covers the different ways to initiate and manage payments.
## The Sonr Payment Model
Sonr payments are built on a capability-based system using UCANs. This means that instead of signing every transaction, users delegate permission to their Vault to execute payments within predefined limits.
<CardGroup>
<Card title="Programmable Payments" href="/blockchain/modules/svc/ucan">
Automate recurring payments and subscriptions with UCANs.
</Card>
<Card title="Cross-Chain Transfers" href="/blockchain/network">
Send assets to other blockchains seamlessly through IBC.
</Card>
<Card title="Token Economics" href="/blockchain/token/">
Learn about token distribution and transaction fees.
</Card>
</CardGroup>
## Sending a Simple Transfer
This example demonstrates how to send a simple transfer from a user's Vault in a browser application.
<Steps>
<Step>
### 1. Authenticate the User
First, ensure the user is authenticated and you have a valid session.
```javascript
import { Sonr } from "@sonr/sdk";
const sonr = new Sonr({ httpUrl: "http://localhost:1317" });
const session = await sonr.authenticate();
```
</Step>
<Step>
### 2. Request Payment Capability
Before sending a payment, your application must request the necessary permission from the user.
```javascript
const paymentCapability = await session.vault.requestCapability({
action: "bank/send",
constraints: {
maxAmount: "10000000usnr", // 10 SNR
to: "snr1..._recipient_address_...",
},
});
if (!paymentCapability.approved) {
throw new Error("Payment not authorized by user");
}
```
</Step>
<Step>
### 3. Execute the Payment
Once you have the capability, you can execute the payment.
```javascript
const result = await session.vault.send({
to: "snr1..._recipient_address_...",
amount: "1000000usnr", // 1 SNR
ucan: paymentCapability.ucan, // Provide the authorized UCAN
});
console.log(`Payment successful! TxHash: ${result.txhash}`);
```
</Step>
</Steps>
## Backend Payments
For backend services, payments can be initiated using a delegated UCAN.
<Steps>
<Step>
### 1. Obtain a Delegated UCAN
Your service must first obtain a delegated UCAN from the user that grants permission to send payments on their behalf.
</Step>
<Step>
### 2. Use the Go SDK to Send
Your Go backend can use the delegated UCAN to send a payment.
```go
package main
import (
"context"
"fmt"
"github.com/sonr-io/sonr/x/sonr/pkgs/sdk"
)
func SendPaymentOnBehalfOfUser(userDID, recipientAddress, amount, delegatedUcan string) error {
sonr, _ := sdk.NewSonr(rpcEndpoint, "")
// The SDK will automatically use the UCAN for authorization
result, err := sonr.SendFrom(userDID, recipientAddress, amount, delegatedUcan)
if err != nil {
return err
}
fmt.Printf("Payment sent! TxHash: %s\n", result.TxHash)
return nil
}
```
</Step>
</Steps>
## Cross-Chain Payments
Sonr supports cross-chain payments through the Inter-Blockchain Communication (IBC) protocol.
### Sending to another IBC-enabled chain
```javascript
const result = await session.vault.send({
to: "osmo1..._recipient_address_...", // An Osmosis address
amount: "1000000usdc", // 1 USDC
via: "ibc/transfer/channel-0", // The IBC channel to use
});
console.log(`Cross-chain payment successful! TxHash: ${result.txhash}`);
```
## Querying Payment History
You can query a user's payment history from their Vault.
```javascript
const history = await session.vault.getPaymentHistory({ limit: 10 });
console.log("Payment History:", history.records);
```
## Next Steps
- [Explore the UCAN authorization model](/blockchain/modules/svc/ucan)
- [Learn about blockchain modules](/blockchain/)
- [See the API Reference](/reference/)
docs/guides/migrate-to-decentralized-authentication.mdx
+191
View File
@@ -0,0 +1,191 @@
---
title: "Migrating from Centralized to Decentralized Authentication"
description: "A comprehensive guide to migrating from centralized 8787 endpoints to decentralized OIDC authentication with WebAuthn"
sidebarTitle: "Decentralized Authentication"
icon: "key"
---
# Migrating from Centralized to Decentralized Authentication
## Overview
Sonr is transitioning from a centralized authentication model using 8787 endpoints to a fully decentralized, privacy-preserving authentication system leveraging OpenID Connect (OIDC), Self-Issued OpenID Provider (SIOP), and WebAuthn technologies.
### Key Improvements
- **Decentralization**: Move from centralized identity management to self-sovereign identity
- **WebAuthn Integration**: Hardware-backed, phishing-resistance authentication
- **Gasless Onboarding**: Zero-cost user registration and transactions
- **Automatic Vault Creation**: Seamless user experience with instant identity setup
- **Enhanced Privacy**: DID-based authentication with verifiable presentations
## Architecture Comparison
### Old Architecture: Centralized 8787 Endpoints
- Centralized authentication server
- Fixed credential storage
- Limited authentication methods
- Higher security risks
### New Architecture: Decentralized OIDC Provider
```mermaid
graph TD
A[User Device] --> B{WebAuthn Registration}
B --> |Credential Generation| C[Blockchain Bridge]
C --> |Broadcast Credential| D[Sonr Blockchain]
D --> |Create DID| E[User's Decentralized Identity]
E --> |SIOP Flow| F[OIDC Provider]
F --> |Verifiable Presentation| G[Service Provider]
```
## Migration Steps
### 1. Prerequisites
- Go 1.24.1+
- Cosmos SDK v0.50.14
- WebAuthn-compatible browser/device
- Updated Sonr SDK
### 2. Configuration Changes
#### Environment Variables
<CodeGroup>
```bash title="Old Configuration"
# Centralized auth endpoints
AUTH_ENDPOINT=https://8787.sonr.io/auth
AUTH_CLIENT_ID=legacy-client-id
```
```bash title="New Configuration"
# Decentralized OIDC configuration
OIDC_PROVIDER_URL=https://oidc.sonr.network
WEBAUTHN_ORIGIN=https://your-app.com
DID_RESOLVER_URL=https://did.sonr.network
```
</CodeGroup>
### 3. Endpoint Migration
| Old Endpoint | New Endpoint | Changes |
| ---------------- | -------------------- | ----------------------- |
| `/auth/login` | `/oidc/authorize` | OIDC authorization flow |
| `/auth/register` | `/webauthn/register` | WebAuthn registration |
| `/auth/token` | `/oidc/token` | Token issuance via SIOP |
### 4. API Changes
#### Request Format
<CodeGroup>
```json title="Legacy Request"
{
"username": "user@example.com",
"password": "legacy-password"
}
```
```json title="New WebAuthn Request"
{
"challenge": "base64-encoded-challenge",
"attestation": {
"type": "public-key",
"id": "credential-id",
"rawId": "base64-encoded-raw-credential",
"response": {
"clientDataJSON": "...",
"attestationObject": "..."
}
}
}
```
</CodeGroup>
### 5. WebAuthn Integration
#### Registration Flow
1. Generate registration challenge
2. Create WebAuthn credential
3. Broadcast credential to blockchain
4. Automatically create user vault
5. Issue decentralized identifier (DID)
#### Code Example
```go title="WebAuthn Registration Handler"
func (s *Server) HandleWebAuthnRegistration(w http.ResponseWriter, r *http.Request) {
// 1. Validate WebAuthn attestation
credential, err := s.webAuthnService.VerifyRegistration(attestationData)
// 2. Broadcast to blockchain
didDoc, err := s.blockchainBridge.CreateDID(credential)
// 3. Create user vault
vault, err := s.vaultService.CreateVault(didDoc)
// 4. Issue OIDC token
token := s.oidcService.IssueToken(didDoc)
}
```
### 6. SIOP (Self-Issued OpenID Provider)
#### Key Concepts
- Verifiable Presentations
- Decentralized Identifiers (DIDs)
- User-controlled authentication
### 7. Error Handling
#### Migration Errors
| Error Code | Description | Mitigation |
| ------------------------ | ---------------------- | -------------------- |
| `AUTH_LEGACY_DEPRECATED` | Legacy auth method | Upgrade client |
| `WEBAUTHN_UNSUPPORTED` | Device incompatibility | Use alternative auth |
| `DID_RESOLUTION_FAILED` | Identity verification | Retry registration |
### 8. Testing Migration
```bash
# Validate WebAuthn registration
sonr webauthn test-registration
# Verify OIDC provider
sonr oidc validate-provider
# Check DID resolution
sonr did resolve did:sonr:example
```
### 9. Breaking Changes
- Legacy password authentication removed
- Token format changed to JWT with DID claims
- New client libraries required
- WebAuthn mandatory for registration
## Rollback Procedure
If issues arise:
1. Maintain legacy user mappings
2. Provide fallback authentication
3. Gradual, opt-in migration
## Conclusion
This migration represents a significant leap in authentication security and user privacy. By adopting WebAuthn, SIOP, and blockchain-backed identities, we're creating a more robust, user-controlled authentication ecosystem.
## Support
- [Sonr Developer Docs](/docs)
- [WebAuthn Specification](https://www.w3.org/TR/webauthn-2/)
- [OIDC Community](https://openid.net/developers/specs/)
docs/guides/motr-usage.mdx
+233
View File
@@ -0,0 +1,233 @@
---
title: "Motor WASM Service Worker Usage"
description: "Comprehensive guide to using the Motor WASM service worker for secure browser-based DWN and Wallet APIs"
icon: "microchip"
sidebarTitle: "Motor WASM"
---
<Info>
Motor is a WebAssembly service worker providing secure, client-side cryptographic operations and decentralized web node (DWN) capabilities.
</Info>
## Overview
Motor is a WebAssembly-powered service worker that enables:
- Secure client-side cryptographic operations
- Decentralized Web Node (DWN) APIs
- Cross-platform support for browsers and Node.js
<CardGroup cols={2}>
<Card title="DWN API" icon="database">
Create, read, update, and delete records with optional encryption
</Card>
<Card title="Wallet API" icon="wallet" color="#22863a">
UCAN token generation, digital signatures, and verification
</Card>
</CardGroup>
## Prerequisites
<Check>
- Node.js 20+ and pnpm
- Browser with Service Worker support
- HTTP/HTTPS server for WASM files
</Check>
## Installation
<CodeGroup>
```bash npm
npm install @sonr.io/es
```
```bash pnpm
pnpm add @sonr.io/es
```
```bash yarn
yarn add @sonr.io/es
```
</CodeGroup>
## Usage Examples
### Basic Initialization
<Tabs>
<Tab title="Browser Auto-Detection">
```typescript
import { createMotorPlugin } from '@sonr.io/es/client/motor';
// Automatically detects browser vs Node.js environment
const plugin = await createMotorPlugin();
// Get issuer DID
const issuer = await plugin.getIssuerDID();
console.log('Issuer DID:', issuer.issuer_did);
```
</Tab>
<Tab title="Browser Service Worker">
```typescript
import { createMotorPluginForBrowser } from '@sonr.io/es/client/motor';
const plugin = await createMotorPluginForBrowser('/motor-worker', {
auto_register_worker: true,
worker_scope: '/',
debug: true,
});
// Create UCAN origin token
const tokenResponse = await plugin.newOriginToken({
audience_did: 'did:sonr:audience123',
attenuations: [{ can: ['sign', 'verify'], with: 'vault://my-vault' }],
});
```
</Tab>
<Tab title="Node.js">
```typescript
import { createMotorPluginForNode } from '@sonr.io/es/client/motor';
const plugin = await createMotorPluginForNode('http://localhost:8080', {
max_retries: 3,
retry_delay: 1000,
timeout: 5000,
debug: true,
});
```
</Tab>
</Tabs>
### Record Operations
<CodeGroup>
```typescript DWN Create
const createResult = await plugin.createRecord({
schema: 'https://schema.org/Person',
data: JSON.stringify({ name: 'Alice Smith' }),
is_encrypted: false,
});
```
```typescript DWN Read
const record = await plugin.readRecord({
record_id: createResult.record_id,
});
```
```typescript DWN Update
await plugin.updateRecord({
record_id: createResult.record_id,
data: JSON.stringify({ name: 'Alice Johnson' }),
});
```
```typescript DWN Delete
const deleteResult = await plugin.deleteRecord({
record_id: createResult.record_id,
});
```
</CodeGroup>
### Encrypted Records
```typescript
const sensitiveData = {
ssn: '123-45-6789',
medical_record: 'Confidential information',
};
const encryptedRecord = await plugin.createRecord({
schema: 'https://schema.org/MedicalRecord',
data: JSON.stringify(sensitiveData),
is_encrypted: true, // Enable encryption
});
// Automatic decryption on read
const decryptedRecord = await plugin.readRecord({
record_id: encryptedRecord.record_id,
});
```
## Deployment
<Tabs>
<Tab title="Development">
```bash
cd dist/wasm
python3 -m http.server 8080
# Access at http://localhost:8080/test.html
```
</Tab>
<Tab title="Production (Nginx)">
```nginx
location /motor/ {
alias /path/to/dist/wasm/;
# CORS and MIME types
add_header 'Access-Control-Allow-Origin' '*';
location ~ \.wasm$ {
add_header 'Content-Type' 'application/wasm';
}
}
```
</Tab>
<Tab title="CDN">
```html
<script src="https://cdn.example.com/motor/wasm_exec.js"></script>
<script>
navigator.serviceWorker.register(
'https://cdn.example.com/motor/motr-sw.js'
);
</script>
```
</Tab>
</Tabs>
## Troubleshooting
<Accordion title="Common Issues">
<Accordion.Panel title="Service Worker Not Registering">
- Ensure HTTPS or localhost
- Check browser console
- Verify service worker file path
</Accordion.Panel>
<Accordion.Panel title="WASM Module Loading">
- Check MIME type: `application/wasm`
- Verify CORS headers
- Match `wasm_exec.js` with Go version
</Accordion.Panel>
</Accordion>
## Browser Compatibility
| Browser | Minimum Version | Support |
|---------|----------------|---------|
| Chrome | 89+ | Full |
| Firefox | 89+ | Full |
| Safari | 15.4+ | Good |
| Edge | 89+ | Full |
<Warning>
Requires HTTPS or localhost for service worker functionality
</Warning>
## Performance Tips
<Tip>
- Use TinyGo for smaller WASM binaries
- Enable browser caching
- Lazy load Motor plugin
- Limit service worker scope
</Tip>
## Support
- **GitHub**: [Issues](https://github.com/sonr-io/sonr/issues)
- **Docs**: [Motor WASM Documentation](https://docs.sonr.io/motor-wasm)
- **Discord**: [Sonr Community](https://discord.gg/sonr)
docs/guides/onboarding.mdx
+279
View File
@@ -0,0 +1,279 @@
---
title: Validator Node Onboarding
description: Complete guide for becoming a Sonr blockchain validator from setup to operations
icon: "boxes"
sidebarTitle: Become a Validator
---
## Overview
Sonr is a Cosmos SDK-based blockchain focused on decentralized identity and asset management. This guide provides comprehensive information for validators interested in securing the Sonr network and participating in its specialized identity infrastructure ecosystem.
<Note>
Sonr is currently in testnet/development phase. While there's no confirmed
mainnet launch date, early participation in testnet operations is highly
recommended for prospective validators.
</Note>
## Network Positioning
Sonr differentiates itself within the Cosmos ecosystem through:
- **Decentralized Identity Focus**: Implementing W3C DID standards and WebAuthn integration
- **Highway Architecture**: Specialized node infrastructure for identity services
- **Fast Wallet Generation**: 600ms wallet creation with IPFS storage capabilities
- **Developer Tools**: React SDKs and identity-focused APIs
## Hardware Requirements
Professional validator operations require substantial infrastructure investment to ensure network security and reliability.
### Essential Specifications
<Card title="CPU">
**Minimum**: 4 cores x86 processor **Recommended**: 8+ cores for production
</Card>
<Card title="RAM">
**Minimum**: 16GB with NVMe swap **Recommended**: 32GB+ for optimal
performance
</Card>
<Card title="Storage">
**Required**: 1TB+ NVMe SSD **Note**: Regular SSDs often insufficient for
I/O demands
</Card>
<Card title="Network">
**Minimum**: 100Mbps dedicated bandwidth **Usage**: Multi-gigabyte daily
traffic expected
</Card>
### Infrastructure Investment
- **Initial Setup**: Professional-grade hardware required for reliable operations
- **Monthly Operating**: Tier 3+ datacenter colocation recommended for optimal performance
- **Redundancy**: Full backup server with identical specifications required
## Quick Setup with NPX
Sonr provides an NPX-based tool to streamline validator deployment:
```bash
npx @sonr/validator-setup my-validator --chain=sonr-testnet-1
```
The interactive wizard guides you through:
<Steps>
<Step>
### Network Configuration Select testnet or mainnet and configure chain
parameters
</Step>
<Step>
### Hardware Verification Automated check of system requirements and
recommendations
</Step>
<Step>### Key Generation Secure key creation with HSM support options</Step>
<Step>
### Sentry Architecture Deploy protective sentry node infrastructure
</Step>
<Step>
### Monitoring Setup Install Prometheus + Grafana monitoring stack
</Step>
<Step>
### Security Hardening Configure firewalls and security best practices
</Step>
</Steps>
## Network Parameters
### Validator Network Structure
For a 50-validator network with 1 billion token supply:
#### Early Network Phase (30% staking ratio)
- **Inflation**: 15% (bootstrap incentives)
- **Validator Participation**: Commission-based earnings structure
- **Delegator Rewards**: High early participation incentives
#### Bootstrap Phase (50% staking ratio)
- **Inflation**: 12% (balanced growth)
- **Validator Participation**: Balanced commission structure
- **Delegator Rewards**: Sustainable growth incentives
#### Mature Network (67% staking ratio)
- **Inflation**: 7% (long-term stability)
- **Validator Participation**: Stable commission structure
- **Delegator Rewards**: Long-term participation incentives
### Recommended Parameters
- **Minimum validator stake**: 1,000,000 SNR (0.1% of supply)
- **Optimal self-bond**: 2,000,000 SNR (0.2% of supply)
- **Commission range**: 5-15% (5% mandatory minimum)
- **Inflation range**: 5-18% with 8% target at 65% staking
- **Unbonding period**: 21 days standard
## Operational Considerations
### Infrastructure Requirements
Validators should ensure adequate infrastructure to support reliable network participation.
### Reward Sources
- **Block Rewards**: Inflation-based token issuance for network security
- **Transaction Fees**: Gas fees and proposer bonuses from network activity
- **Additional Rewards**: ICS rewards, cross-chain fees, and ecosystem participation
## Security Architecture
### Sentry Node Design
Implement a multi-layered security approach:
```
Internet → Sentry Nodes (3-5) → Private Network → Validator Node
```
### Critical Security Implementations
<Card title="Key Management">
- Hardware Security Modules (HSM) - Tendermint Key Management System (TMKMS)
- Remote signing capabilities
</Card>
<Card title="Network Security">
- Geographic distribution across datacenters - Automated double-sign
prevention - Comprehensive monitoring and alerting
</Card>
<Card title="Operational Security">
- 99.9%+ uptime requirements - Encrypted backups across locations - Strict
access controls and audits
</Card>
### Key Types
1. **Consensus Key**: Hot key for block signing (ed25519)
2. **Operator Key**: Cold storage for validator transactions (secp256k1)
3. **Node Key**: P2P network identification
## Implementation Roadmap
### Phase 1: Testnet Participation (Months 1-3)
<Note type="warning">
Begin with testnet operations to gain experience without operational risk.
</Note>
- Hardware procurement and datacenter setup
- Team training on Cosmos SDK operations
- Security procedure development
- Community engagement and reputation building
### Phase 2: Infrastructure Preparation (Month 4)
- Deploy production hardware in Tier 3+ datacenters
- Implement sentry node architecture across regions
- Configure monitoring and alerting systems
- Establish 24/7 operational procedures
### Phase 3: Mainnet Genesis (Month 5+)
- Participate in genesis ceremony
- Self-bond required SNR tokens (1-2M recommended)
- Configure optimal commission rates (start at 5-7%)
- Launch validator with foundation delegation support
### Phase 4: Operational Excellence (Ongoing)
- Maintain 99.9%+ uptime through redundant systems
- Actively participate in governance proposals
- Provide regular updates to delegators
- Contribute to ecosystem development
## Foundation Support Programs
### Delegation Program
Sonr implements a foundation delegation program allocating 10-15% of total supply:
- **Coverage**: 30-35 validators (60-70% of active set)
- **Requirements**: 3-month testnet participation
- **Terms**: 6-12 month delegation periods
- **Renewal**: Performance-based criteria
- **Focus**: Geographic distribution and community contributions
### Testnet Incentives
- **Monthly Rewards**: Testnet participation incentives for active validators
- **Mainnet Slots**: Top performers receive guaranteed mainnet positions
- **Foundation Delegations**: 6-month delegations of 2M tokens for top testnet validators
## Monitoring and Operations
### Prometheus Metrics
- System metrics (CPU, RAM, disk, network)
- Tendermint consensus metrics (height, voting power, peer count)
- Custom application metrics (missed blocks, proposal statistics)
### Critical Alerts
- Low peer count (less than 5 peers)
- High block time intervals
- Resource utilization warnings
- Disk space projections
### Grafana Dashboards
- Real-time performance monitoring
- Historical trend analysis
- Multi-validator comparison views
## Risk Management
### Technical Risks
- **Double-signing prevention**: Proper key management and TMKMS
- **State corruption recovery**: Automated backup systems
- **Network partitions**: Geographic distribution strategies
- **Upgrade failures**: Staging environment testing
### Operational Risks
- **Network participation**: Maintain consistent validator performance
- **Delegation concentration**: Limits on single delegator exposure
- **Commission optimization**: Community-competitive rates
- **Infrastructure management**: Efficient operational procedures
## Future Opportunities
As Sonr matures, validators can explore additional network services:
- **Relayer Operations**: IBC connection services
- **RPC Endpoints**: Developer infrastructure services
- **Archive Nodes**: Historical data provision
- **Identity Services**: Custom solutions leveraging Sonr infrastructure
- **Interchain Security**: Consumer chain participation
## Getting Started
<Card title="Join Testnet" href="/guides/validators/testnet">
Start with testnet participation to gain operational experience
</Card>
<Card title="Hardware Setup" href="/guides/validators/setup">
Detailed hardware and infrastructure deployment guide
</Card>
<Card title="Security Guide" href="/guides/validators/security">
Comprehensive security implementation and best practices
</Card>
<Card title="Monitoring" href="/guides/validators/monitoring">
Setup monitoring and alerting systems for your validator
</Card>
<Note type="success">
Sonr presents a compelling opportunity for validators seeking exposure to the
decentralized identity market within the Cosmos ecosystem. Early preparation
and professional operations are key to success.
</Note>
docs/guides/pdk-environment.mdx
+172
View File
@@ -0,0 +1,172 @@
---
title: "PDK Environment Configuration"
description: "Comprehensive guide to configuring the Pluggable Development Kit (PDK) for Sonr plugins"
icon: "gear"
---
# PDK Environment Configuration
The Pluggable Development Kit (PDK) provides a flexible configuration system for managing plugin environments, MPC enclaves, and runtime settings.
## Environment Variables
### Core PDK Variables
| Variable | Type | Description | Default |
| -------------- | -------- | --------------------------------- | ------------------ |
| `chain_id` | `string` | Target blockchain network | `"sonr-testnet-1"` |
| `enclave` | `object` | MPC enclave configuration | `{}` |
| `vault_config` | `object` | Vault and key management settings | `{}` |
| `log_level` | `string` | Logging verbosity | `"info"` |
## Enclave Configuration
### Basic Enclave Setup
```json
{
"enclave": {
"id": "unique-enclave-identifier",
"key_type": "secp256k1",
"threshold": 2,
"participants": [
{ "id": "participant1", "public_key": "..." },
{ "id": "participant2", "public_key": "..." }
]
}
}
```
### Advanced Enclave Parameters
```json
{
"enclave": {
"security_level": "high",
"attestation_mode": "remote",
"key_rotation_interval": "1h",
"backup_strategy": "distributed"
}
}
```
## Vault Configuration
### Key Management Settings
```json
{
"vault_config": {
"storage_backend": "ipfs",
"encryption": {
"algorithm": "aes-256-gcm",
"key_derivation": "pbkdf2"
},
"access_control": {
"mode": "role-based",
"default_role": "viewer"
}
}
}
```
## Logging Configuration
```json
{
"log_level": "debug",
"log_format": "json",
"log_outputs": [
{ "type": "stdout" },
{ "type": "file", "path": "/var/log/sonr/pdk.log" }
]
}
```
## Performance Tuning
```json
{
"performance": {
"max_concurrent_tasks": 10,
"task_timeout": "5m",
"memory_limit": "512MB",
"cpu_allocation": 2
}
}
```
## Security Hardening
```json
{
"security": {
"require_mfa": true,
"allowed_key_types": ["secp256k1", "ed25519"],
"audit_logging": true,
"rate_limiting": {
"max_requests_per_minute": 100
}
}
}
```
## Plugin-Specific Configuration
```json
{
"plugins": {
"motor": {
"mpc_mode": "distributed",
"token_generation_rate_limit": 10
},
"did": {
"supported_methods": ["did:key", "did:sonr"]
}
}
}
```
## Environment Loading Precedence
1. Environment Variables
2. Configuration Files
3. Default Values
## Best Practices
- Use environment-specific configurations
- Implement strict access controls
- Rotate encryption keys regularly
- Monitor and log configuration changes
- Use minimal privilege principles
## Example Configuration Loading
```go
func loadPDKConfiguration() (*PDKConfig, error) {
// Load from environment variables
config := &PDKConfig{}
// Override with config file if exists
configFile, err := ioutil.ReadFile("/etc/sonr/pdk.json")
if err == nil {
json.Unmarshal(configFile, config)
}
return config, nil
}
```
## Troubleshooting
- Check `log_level` for detailed diagnostics
- Validate JSON configuration syntax
- Verify key and enclave configurations
## Advanced Topics
For more complex PDK configurations, refer to:
- [DWN Plugin Documentation](/blockchain/modules/dwn/plugin)
- [DWN Architecture Overview](/blockchain/modules/dwn/architecture)
docs/guides/register-records.mdx
+7
View File
@@ -0,0 +1,7 @@
---
title: "Registering a Domain"
description: "Comprehensive guide to creating, validating, and managing User-Controlled Authorization Network (UCAN) tokens"
icon: "key"
---
docs/guides/signin-with-sonr.mdx
+438
View File
@@ -0,0 +1,438 @@
---
title: "Sign in with Sonr: Developer Guide"
description: "OAuth 2.0 authentication for decentralized applications with UCAN capabilities"
sidebarTitle: "Sign in with Sonr"
icon: "key"
---
<Info>
This guide covers OAuth 2.0 authentication for decentralized applications using Sonr's advanced Web3 capabilities.
</Info>
## Overview
Sign in with Sonr provides OAuth 2.0 authentication for decentralized applications, combining traditional OAuth flows with Web3 capabilities through UCAN (User Controlled Authorization Networks) delegation.
<CardGroup cols={2}>
<Card title="OAuth 2.0 + OIDC" icon="lock">
Industry-standard authentication with OpenID Connect
</Card>
<Card title="WebAuthn Support" icon="fingerprint">
Passwordless authentication with hardware security
</Card>
<Card title="UCAN Capabilities" icon="network">
Fine-grained permission delegation for Web3
</Card>
<Card title="Decentralized Identity" icon="id-card">
W3C DID-based identity management
</Card>
</CardGroup>
## Quick Start
### Installation
<CodeGroup>
```bash npm
npm install @sonr.io/ui
```
```bash pnpm
pnpm add @sonr.io/ui
```
```bash yarn
yarn add @sonr.io/ui
```
</CodeGroup>
### Basic Implementation
<CodeGroup>
```tsx React
import { SignInWithSonr } from '@sonr.io/ui';
function App() {
return (
<SignInWithSonr
clientId="your-client-id"
redirectUri="http://localhost:3000/callback"
scopes={['openid', 'profile', 'vault:read']}
/>
);
}
```
</CodeGroup>
## Configuration
### OAuth Client Registration
<CodeGroup>
```typescript Configuration
const clientConfig = {
clientId: 'your-client-id',
clientSecret: 'your-client-secret', // Only for confidential clients
redirectUris: ['http://localhost:3000/callback'],
grantTypes: ['authorization_code', 'refresh_token'],
responseTypes: ['code'],
scopes: ['openid', 'profile', 'vault:read', 'vault:write'],
tokenEndpointAuthMethod: 'none', // For public clients
};
```
</CodeGroup>
### Environment Variables
<CodeGroup>
```env OAuth Endpoints
# OAuth Endpoints
NEXT_PUBLIC_SONR_CLIENT_ID=your-client-id
NEXT_PUBLIC_REDIRECT_URI=http://localhost:3000/callback
NEXT_PUBLIC_AUTH_URL=https://auth.sonr.io/oauth/authorize
NEXT_PUBLIC_TOKEN_URL=https://auth.sonr.io/oauth/token
NEXT_PUBLIC_USERINFO_URL=https://auth.sonr.io/oauth/userinfo
```
</CodeGroup>
## OAuth Scopes & UCAN Capabilities
<Tabs>
<Tab title="Standard Scopes">
<table>
<thead>
<tr>
<th>Scope</th>
<th>Description</th>
<th>UCAN Capabilities</th>
</tr>
</thead>
<tbody>
<tr>
<td>`openid`</td>
<td>OpenID Connect identity</td>
<td>Basic identity claims</td>
</tr>
<tr>
<td>`profile`</td>
<td>User profile information</td>
<td>Name, picture, metadata</td>
</tr>
<tr>
<td>`email`</td>
<td>Email address</td>
<td>Email and verification status</td>
</tr>
<tr>
<td>`offline_access`</td>
<td>Refresh token issuance</td>
<td>Long-lived access</td>
</tr>
</tbody>
</table>
</Tab>
<Tab title="Vault Scopes">
<table>
<thead>
<tr>
<th>Scope</th>
<th>Description</th>
<th>UCAN Actions</th>
</tr>
</thead>
<tbody>
<tr>
<td>`vault:read`</td>
<td>Read vault contents</td>
<td>`vault/read`, `vault/list`</td>
</tr>
<tr>
<td>`vault:write`</td>
<td>Modify vault contents</td>
<td>`vault/write`, `vault/create`, `vault/update`</td>
</tr>
<tr>
<td>`vault:delete`</td>
<td>Delete vault items</td>
<td>`vault/delete`</td>
</tr>
<tr>
<td>`vault:admin`</td>
<td>Full vault control</td>
<td>All vault actions</td>
</tr>
</tbody>
</table>
</Tab>
</Tabs>
## Integration Examples
<Tabs>
<Tab title="React Hooks">
<CodeGroup>
```tsx React Hooks
import { useSignInWithSonr } from '@sonr.io/ui';
function LoginComponent() {
const {
user,
token,
isAuthenticated,
isLoading,
signIn,
signOut,
refreshToken,
} = useSignInWithSonr({
clientId: 'your-client-id',
redirectUri: 'http://localhost:3000/callback',
scopes: ['openid', 'profile', 'vault:read'],
});
if (isLoading) return <div>Loading...</div>;
if (isAuthenticated) {
return (
<div>
<p>Welcome, {user.name}!</p>
<button onClick={signOut}>Sign Out</button>
</div>
);
}
return <button onClick={signIn}>Sign in with Sonr</button>;
}
```
</CodeGroup>
</Tab>
<Tab title="Next.js App Router">
<CodeGroup>
```tsx Next.js Layout
// app/layout.tsx
import { AuthProvider } from '@/components/AuthProvider';
export default function RootLayout({ children }) {
return (
<html>
<body>
<AuthProvider>{children}</AuthProvider>
</body>
</html>
);
}
```
```tsx Auth Provider
'use client';
import { createContext, useContext, useEffect, useState } from 'react';
import { OAuth2Client } from '@sonr.io/ui';
const AuthContext = createContext();
export function AuthProvider({ children }) {
const [client] = useState(() => new OAuth2Client({
clientId: process.env.NEXT_PUBLIC_SONR_CLIENT_ID,
redirectUri: process.env.NEXT_PUBLIC_REDIRECT_URI,
}));
// ... authentication logic
return (
<AuthContext.Provider value={{ client, /* ... */ }}>
{children}
</AuthContext.Provider>
);
}
export const useAuth = () => useContext(AuthContext);
```
</CodeGroup>
</Tab>
</Tabs>
## Advanced Features
### Custom Authorization
<CodeGroup>
```tsx Custom Authorization
<SignInWithSonr
clientId="your-client-id"
redirectUri="http://localhost:3000/callback"
authorizationUrl="https://auth.sonr.io/oauth/authorize"
state={generateRandomState()} // CSRF protection
scopes={['openid', 'profile', 'vault:admin']}
// Additional parameters
onAuthStart={() => console.log('Starting auth...')}
onAuthError={(error) => console.error('Auth failed:', error)}
/>
```
</CodeGroup>
### Token Management
<CodeGroup>
```typescript Token Management
const client = new OAuth2Client(config);
// Check authentication status
if (client.isAuthenticated()) {
// Get current access token
const accessToken = client.getAccessToken();
// Refresh token before expiry
const newToken = await client.refreshToken();
// Get user information
const userInfo = await client.getUserInfo();
// Revoke tokens on logout
await client.logout();
}
```
</CodeGroup>
## Security Considerations
<Warning>
Always implement robust security practices when integrating authentication.
</Warning>
### PKCE Implementation
<CodeGroup>
```typescript PKCE Configuration
const client = new OAuth2Client({
clientId: 'public-client',
pkce: true, // Enabled by default for public clients
});
```
</CodeGroup>
### State Parameter Prevention
<CodeGroup>
```typescript State Validation
// Generate random state
const state = crypto.randomUUID();
sessionStorage.setItem('oauth_state', state);
// Validate on callback
const returnedState = params.get('state');
const savedState = sessionStorage.getItem('oauth_state');
if (returnedState !== savedState) {
throw new Error('State mismatch - possible CSRF attack');
}
```
</CodeGroup>
## Troubleshooting
<Accordion title="Common Authentication Issues">
<AccordionItem title="CORS Errors">
- Ensure your redirect URI is whitelisted
- Check allowed origins in OAuth server config
</AccordionItem>
<AccordionItem title="Invalid Grant">
- Authorization code can only be used once
- Code expires after 10 minutes
- Verify redirect URI matches exactly
</AccordionItem>
<AccordionItem title="Token Expiry">
- Implement automatic refresh before expiry
- Handle refresh token rotation
</AccordionItem>
</Accordion>
<Note>
Enable debug mode for additional troubleshooting insights:
```typescript
const client = new OAuth2Client({
clientId: 'your-client-id',
debug: true, // Enable console logging
});
```
</Note>
## API Reference
### SignInWithSonr Props
```typescript
interface SignInWithSonrProps {
clientId: string;
redirectUri: string;
authorizationUrl?: string;
scopes?: string[];
state?: string;
variant?: 'default' | 'outline' | 'ghost' | 'dark';
size?: 'default' | 'sm' | 'lg';
isLoading?: boolean;
text?: string;
showLogo?: boolean;
onAuthStart?: () => void;
onAuthError?: (error: Error) => void;
}
```
## Resources
<CardGroup cols={2}>
<Card
title="OAuth 2.0 Specification"
href="https://datatracker.ietf.org/doc/html/rfc6749"
>
RFC 6749 - OAuth 2.0 Authorization Framework
</Card>
<Card
title="OpenID Connect"
href="https://openid.net/specs/openid-connect-core-1_0.html"
>
Core specification for identity layers
</Card>
<Card
title="UCAN Specification"
href="https://github.com/ucan-wg/spec"
>
User Controlled Authorization Networks
</Card>
<Card
title="WebAuthn"
href="https://www.w3.org/TR/webauthn/"
>
Web Authentication API specification
</Card>
</CardGroup>
## Support
<CardGroup cols={3}>
<Card
title="GitHub"
icon="github"
href="https://github.com/sonr-io/sonr"
>
Report issues or contribute
</Card>
<Card
title="Documentation"
icon="book"
href="https://sonr.dev"
>
Explore full documentation
</Card>
<Card
title="Discord"
icon="discord"
href="https://discord.gg/sonr"
>
Join our community
</Card>
</CardGroup>
docs/guides/vault-plugin-usage.mdx
+286
View File
@@ -0,0 +1,286 @@
---
title: "Sonr Vault Plugin with Dexie.js Persistence"
description: "Comprehensive guide to using the Sonr Vault Plugin with persistent storage and multi-account support"
sidebarTitle: "Vault Plugin Usage"
icon: "lock"
---
# Sonr Vault Plugin: Persistent Storage and Account Management
## Overview
The Sonr Vault Plugin provides a powerful, secure, and flexible way to manage cryptographic operations with persistent storage using Dexie.js and IndexedDB. This guide will walk you through the plugin's features, setup, and advanced usage patterns.
<Callout type="info">
**Key Features**
- 🔐 Account-based database separation
- 💾 Automatic token persistence
- 🔄 Cross-browser IndexedDB support
- ⚡ Backward compatibility
- 🧹 Automatic token and session cleanup
</Callout>
## Installation
Install the Sonr Vault Plugin in your project:
<CodeGroup>
```bash npm
npm install @sonr.io/es
```
```bash yarn
yarn add @sonr.io/es
```
```bash pnpm
pnpm add @sonr.io/es
```
</CodeGroup>
## Basic Usage
### Without Persistence (Default)
The vault plugin is designed to be backward compatible. By default, it operates without persistent storage:
```typescript
import { createVaultClient } from '@sonr.io/es/plugins/vault';
// Create a vault client without persistence
const vault = createVaultClient();
// Initialize the vault
await vault.initialize();
// Create tokens and perform operations as before
const token = await vault.newOriginToken({
audience_did: 'did:example:123',
});
```
### With Persistence Enabled
Enable persistent storage with a simple configuration:
```typescript
import { createVaultClient } from '@sonr.io/es/plugins/vault';
// Create a vault client with persistence
const vault = createVaultClient({
enablePersistence: true,
autoCleanup: true, // Automatically clean up expired tokens
cleanupInterval: 3600000 // Cleanup every hour (in milliseconds)
});
// Initialize with an account address for database separation
const accountAddress = 'sonr1abc123...';
await vault.initialize('/plugin.wasm', accountAddress);
// Tokens are now automatically persisted
const token = await vault.newOriginToken({
audience_did: 'did:example:123',
});
```
## Advanced Features
### Multi-Account Support
Seamlessly switch between accounts and manage their individual databases:
```typescript
// Switch to a different account
await vault.switchAccount('sonr1account2');
// List all accounts with persisted data
const accounts = await vault.listPersistedAccounts();
// Remove an account's data
await vault.removeAccount('sonr1account1');
```
### Token Management
Manually manage persisted tokens:
```typescript
// Get all saved tokens
const tokens = await vault.getPersistedTokens();
// Save a specific token
await vault.saveToken({
token: 'eyJ...',
issuer: 'did:sonr:example',
address: 'sonr1abc...',
});
// Remove expired tokens
await vault.removeExpiredTokens();
```
### State Management
Control vault state persistence:
```typescript
// Manually save current state
await vault.persistState();
// Load persisted state
const state = await vault.loadPersistedState();
// Clear all persisted data for the current account
await vault.clearPersistedState();
```
## Storage Management
Use the `VaultStorageManager` for advanced storage operations:
```typescript
import { VaultStorageManager } from '@sonr.io/es/plugins/vault';
const storageManager = new VaultStorageManager({
enablePersistence: true,
});
// Request persistent storage
const isPersisted = await storageManager.requestPersistentStorage();
// Check storage status and estimate
const status = await storageManager.tryPersistWithoutPromptingUser();
const estimate = await storageManager.getStorageEstimate();
```
## Configuration Options
Customize the vault's storage behavior:
<TypeTable
columns={[
{ name: 'enablePersistence', type: 'boolean', description: 'Enable IndexedDB storage' },
{ name: 'storageQuotaRequest', type: 'number', description: 'Storage quota to request in bytes' },
{ name: 'autoCleanup', type: 'boolean', description: 'Enable automatic token/session cleanup' },
{ name: 'cleanupInterval', type: 'number', description: 'Cleanup interval in milliseconds' }
]}
/>
## Browser Compatibility
The Vault Plugin works with most modern browsers:
<Table>
<TableHead>
<TableRow>
<TableCell>Browser</TableCell>
<TableCell>Minimum Version</TableCell>
</TableRow>
</TableHead>
<TableBody>
<TableRow>
<TableCell>Chrome/Edge</TableCell>
<TableCell>23+</TableCell>
</TableRow>
<TableRow>
<TableCell>Firefox</TableCell>
<TableCell>16+</TableCell>
</TableRow>
<TableRow>
<TableCell>Safari</TableCell>
<TableCell>10+</TableCell>
</TableRow>
<TableRow>
<TableCell>Opera</TableCell>
<TableCell>15+</TableCell>
</TableRow>
<TableRow>
<TableCell>iOS Safari</TableCell>
<TableCell>10+</TableCell>
</TableRow>
<TableRow>
<TableCell>Chrome for Android</TableCell>
<TableCell>All versions</TableCell>
</TableRow>
</TableBody>
</Table>
## Storage Limits
Storage availability varies by browser:
<Table>
<TableHead>
<TableRow>
<TableCell>Browser</TableCell>
<TableCell>Storage Limit</TableCell>
</TableRow>
</TableHead>
<TableBody>
<TableRow>
<TableCell>Chrome/Edge</TableCell>
<TableCell>60% of total disk space</TableCell>
</TableRow>
<TableRow>
<TableCell>Firefox</TableCell>
<TableCell>50% of free disk space</TableCell>
</TableRow>
<TableRow>
<TableCell>Safari</TableCell>
<TableCell>Starts at 1GB, can request more</TableCell>
</TableRow>
<TableRow>
<TableCell>Mobile Browsers</TableCell>
<TableCell>Varies by device</TableCell>
</TableRow>
</TableBody>
</Table>
## Security Considerations
<Callout type="warning">
- Databases are isolated by account address
- No private keys or sensitive cryptographic material are stored
- Only UCAN tokens and metadata are persisted
- Always use HTTPS in production
- Consider encrypting sensitive data before storage
</Callout>
## Troubleshooting
### Storage Not Persisting
1. Verify you're running on HTTPS
2. Check that IndexedDB is enabled in browser settings
3. Confirm available storage quota
4. Explicitly request persistent storage
```typescript
try {
await vault.initialize('/plugin.wasm', accountAddress);
} catch (error) {
if (error.code === 'VAULT_NOT_INITIALIZED') {
// Handle initialization error
}
}
```
## Migration Guide
To migrate from non-persistent to persistent storage:
```typescript
// Before (non-persistent)
const vault = createVaultClient();
await vault.initialize();
// After (with persistence)
const vault = createVaultClient({
enablePersistence: true,
});
await vault.initialize('/plugin.wasm', accountAddress);
```
<Callout type="success">
**No other code changes are required!** All existing methods work the same way.
</Callout>
docs/guides/vrf-key-management.mdx
+294
View File
@@ -0,0 +1,294 @@
---
title: VRF Key Management
description: Guide to managing VRF keys for multi-validator encryption
---
# VRF Key Management
VRF (Verifiable Random Function) keys are essential for consensus-based encryption in multi-validator Sonr networks. This guide explains how VRF keys work, how to manage them, and how to troubleshoot common issues.
## Overview
VRF keys enable:
- **Deterministic randomness** in distributed systems
- **Multi-validator encryption** key derivation
- **Consensus-based key rotation** when validator sets change
- **Secure encryption** without requiring shared secrets
## Automatic Generation
VRF keys are automatically generated when you initialize a new node:
```bash
snrd init <moniker> --chain-id sonrtest_1-1
```
This creates:
- VRF keypair at `~/.sonr/vrf_secret.key`
- Deterministic generation from chain-id
- Secure 0600 permissions (owner read/write only)
## VRF Key Commands
The `snrd keys vrf` command suite provides complete VRF key management:
### Show VRF Key Information
Display your node's VRF public key and verify configuration:
```bash
snrd keys vrf show
```
Example output:
```
VRF Key Information:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Key Path: /home/user/.sonr/vrf_secret.key
Public Key: d2d8f52119ba12f7f41b004314e3d040526393f09ba434f5b4196c4242ddac0d
Key Size: 64 bytes
Public Key Size: 32 bytes
Permissions: -rw-------
Modified: 2025-09-27 00:33:11
✓ VRF keys are properly configured
```
### Verify VRF Functionality
Test that VRF keys are working correctly:
```bash
snrd keys vrf verify
```
This performs:
- VRF key loading
- Public key derivation
- Test VRF computation with proof
- Cryptographic verification
### Generate New VRF Keys
Generate or regenerate VRF keys (with backup):
```bash
# Generate for current chain
snrd keys vrf generate
# Generate for specific chain
snrd keys vrf generate --chain-id sonrtest_1-1
# Force regenerate (creates backup)
snrd keys vrf generate --force
```
**⚠️ Warning**: Regenerating VRF keys will invalidate existing consensus-based encryption keys. Only do this if you understand the implications.
## Multi-Validator Testnet Setup
When setting up a multi-validator testnet, ensure each validator generates unique VRF keys:
### Using Scripts
The testnet scripts automatically generate VRF keys:
```bash
# Single node testnet
CHAIN_ID="sonrtest_1-1" CLEAN=true bash scripts/test_node.sh
# Multi-node testnet with Starship
make start
```
### Manual Setup
For manual validator setup:
1. **Initialize each validator**:
```bash
snrd init validator-01 --chain-id sonrtest_1-1
```
2. **Verify VRF keys**:
```bash
snrd keys vrf verify
```
3. **Check permissions**:
```bash
ls -la ~/.sonr/vrf_secret.key
# Should show: -rw------- (0600)
```
## Encryption Configuration
VRF keys are only required when encryption is enabled. You can control encryption via module parameters:
### Check Encryption Status
```bash
snrd query dwn params
```
Look for the `encryption_enabled` field.
### Disable Encryption
If you don't need encryption features, you can disable them:
```bash
# Via governance proposal
snrd tx gov submit-proposal param-change proposal.json
```
With `proposal.json`:
```json
{
"title": "Disable DWN Encryption",
"description": "Disable encryption features",
"changes": [
{
"subspace": "dwn",
"key": "EncryptionEnabled",
"value": "false"
}
]
}
```
## Troubleshooting
### Error: "VRF keys not loaded"
**Cause**: VRF keys are missing or corrupted.
**Solution**:
1. Check if keys exist:
```bash
ls -la ~/.sonr/vrf_secret.key
```
2. If missing, generate keys:
```bash
snrd keys vrf generate --chain-id sonrtest_1-1
```
3. If present but corrupted, regenerate:
```bash
snrd keys vrf generate --force
```
### Error: "Failed to check and perform key rotation"
**Cause**: VRF keys not available during EndBlock, but encryption is enabled.
**Solution**:
1. Verify VRF keys:
```bash
snrd keys vrf verify
```
2. Or disable encryption if not needed:
```bash
# Check current params
snrd query dwn params
# Submit governance proposal to disable
```
### Incorrect Permissions
**Cause**: VRF key file has insecure permissions.
**Fix**:
```bash
chmod 0600 ~/.sonr/vrf_secret.key
```
### Single-Node vs Multi-Validator
- **Single-node development**: Works without VRF keys (deterministic fallback)
- **Multi-validator testnet**: Requires VRF keys for consensus encryption
- **Production**: Always use VRF keys with proper security
## Security Best Practices
### Key Storage
- **Never share** VRF private keys between validators
- **Backup** VRF keys securely (offline storage)
- **Rotate** validator nodes if keys are compromised
- **Monitor** file permissions regularly
### File Permissions
Always ensure restrictive permissions:
```bash
# Check permissions
ls -la ~/.sonr/vrf_secret.key
# Fix if needed
chmod 0600 ~/.sonr/vrf_secret.key
chown $(whoami):$(whoami) ~/.sonr/vrf_secret.key
```
### Key Backup
Backup your VRF keys securely:
```bash
# Create encrypted backup
tar -czf vrf-backup.tar.gz -C ~/.sonr vrf_secret.key
gpg --symmetric --cipher-algo AES256 vrf-backup.tar.gz
# Store vrf-backup.tar.gz.gpg securely offline
```
### Recovery
Restore from backup:
```bash
# Decrypt backup
gpg --decrypt vrf-backup.tar.gz.gpg > vrf-backup.tar.gz
# Extract to correct location
tar -xzf vrf-backup.tar.gz -C ~/.sonr/
# Verify permissions
chmod 0600 ~/.sonr/vrf_secret.key
snrd keys vrf verify
```
## Advanced Topics
### Deterministic Generation
VRF keys are generated deterministically from the chain-id using SHA256. This means:
- Same chain-id = same VRF keys
- Different validators should use different chain configurations
- Re-running `snrd init` with same chain-id produces same keys
### VRF Algorithm
Sonr uses **VRF based on Ed25519** (Curve25519):
- Private key: 64 bytes (32 bytes secret + 32 bytes public)
- Public key: 32 bytes
- Proof: 80 bytes
- Output: 32 bytes of verifiable randomness
### Consensus Encryption
Multi-validator encryption key derivation:
1. Each validator computes VRF output from consensus input
2. VRF outputs are combined to derive encryption key
3. Automatic rotation when validator set changes
4. Keys are never transmitted over network
## See Also
- [Configure Local Node](/guides/configure-local-node) - Node setup guide
- [Development](/guides/development) - Development environment setup
- [Deployment](/guides/deployment) - Production deployment guide
docs/guides/vrf-migration.mdx
+562
View File
@@ -0,0 +1,562 @@
---
title: VRF Key Migration Guide
description: Migrate existing validator nodes to use VRF keys without downtime
---
# VRF Key Migration Guide
This guide provides step-by-step instructions for adding VRF keys to existing Sonr validator nodes that were initialized before VRF key support was added.
## Overview
VRF (Verifiable Random Function) keys are required for:
- Multi-validator encryption features (added in v0.1.12)
- Consensus-based key rotation
- Secure encryption key derivation
Existing nodes initialized before v0.1.12 may not have VRF keys generated.
## Pre-Migration Checklist
Before starting the migration:
- [ ] **Backup** your validator keys and configuration
- [ ] **Identify** which validators need VRF keys
- [ ] **Plan** migration during low-traffic period
- [ ] **Coordinate** with other validators (for governance proposals)
- [ ] **Test** on testnet first
## Migration Scenarios
### Scenario 1: Encryption Not Needed
If your network doesn't use encryption features, you can disable encryption instead of generating VRF keys.
**Option A: Disable via Governance**
1. Create governance proposal:
```bash
cat > disable-encryption-proposal.json <<EOF
{
"messages": [
{
"@type": "/cosmos.params.v1beta1.MsgUpdateParams",
"authority": "sonr10d07y265gmmuvt4z0w9aw880jnsr700j8yv32t",
"params": {
"encryption_enabled": false
}
}
],
"metadata": "Disable encryption until VRF keys are configured",
"deposit": "10000000usnr",
"title": "Disable DWN Encryption",
"summary": "Temporary disable encryption to allow gradual VRF key rollout"
}
EOF
```
2. Submit proposal:
```bash
snrd tx gov submit-proposal disable-encryption-proposal.json \
--from validator \
--chain-id sonrtest_1-1 \
--gas auto \
--gas-adjustment 1.5
```
3. Vote and wait for execution.
**Option B: Genesis Parameter (New Networks Only)**
For new networks, set in genesis:
```json
{
"app_state": {
"dwn": {
"params": {
"encryption_enabled": false
}
}
}
}
```
### Scenario 2: Gradual Migration (Recommended)
Migrate validators one at a time to minimize risk.
**Step 1: Disable Encryption Temporarily**
Follow Scenario 1, Option A to disable encryption via governance.
**Step 2: Generate VRF Keys for Each Validator**
On each validator node:
1. **Stop the validator** (optional, but recommended):
```bash
systemctl stop snrd
# or
pkill snrd
```
2. **Generate VRF keys**:
```bash
snrd keys vrf generate --chain-id sonrtest_1-1
```
3. **Verify generation**:
```bash
snrd keys vrf show
snrd keys vrf verify
```
4. **Check permissions**:
```bash
ls -la ~/.sonr/vrf_secret.key
# Should show: -rw------- (0600)
```
5. **Restart validator**:
```bash
systemctl start snrd
# or start manually
```
6. **Verify node is syncing**:
```bash
snrd status | jq '.SyncInfo'
```
**Step 3: Verify All Validators Have VRF Keys**
On each validator, run:
```bash
snrd keys vrf verify
```
All validators should show:
```
✓ VRF keys are fully functional
```
**Step 4: Re-enable Encryption**
Once all validators have VRF keys:
1. Create governance proposal:
```bash
cat > enable-encryption-proposal.json <<EOF
{
"messages": [
{
"@type": "/cosmos.params.v1beta1.MsgUpdateParams",
"authority": "sonr10d07y265gmmuvt4z0w9aw880jnsr700j8yv32t",
"params": {
"encryption_enabled": true
}
}
],
"metadata": "Re-enable encryption after VRF key deployment",
"deposit": "10000000usnr",
"title": "Enable DWN Encryption",
"summary": "Re-enable encryption now that all validators have VRF keys"
}
EOF
```
2. Submit and execute proposal.
### Scenario 3: Coordinated Network Upgrade
For critical production networks, coordinate a network-wide upgrade.
**Phase 1: Preparation (1-2 weeks before)**
1. **Announce upgrade** to all validators
2. **Share migration plan** and timeline
3. **Test on testnet** with same validator set
4. **Prepare rollback plan**
**Phase 2: Pre-Upgrade (1 day before)**
1. **Verify all validators** are ready:
```bash
# Check validator set
snrd query staking validators --output json | jq '.validators[] | {moniker, status}'
```
2. **Backup critical data**:
```bash
# Backup validator state
tar -czf validator-backup-$(date +%Y%m%d).tar.gz \
~/.sonr/config/ \
~/.sonr/data/priv_validator_state.json
```
3. **Sync upgrade binary**:
```bash
# Ensure all validators have same version
snrd version
```
**Phase 3: Migration Window**
1. **Stop network** at agreed block height:
```bash
# All validators stop
systemctl stop snrd
```
2. **Generate VRF keys** on each validator:
```bash
snrd keys vrf generate --chain-id sonrtest_1-1
snrd keys vrf verify
```
3. **Verify permissions**:
```bash
chmod 0600 ~/.sonr/vrf_secret.key
```
4. **Restart validators** in coordination:
```bash
systemctl start snrd
```
5. **Monitor network recovery**:
```bash
# Watch consensus
snrd status | jq '.SyncInfo.catching_up'
# Watch block production
watch -n 1 'snrd status | jq ".SyncInfo.latest_block_height"'
```
**Phase 4: Post-Migration Verification**
1. **Check all validators online**:
```bash
snrd query tendermint-validator-set | jq '.validators[].address'
```
2. **Verify VRF functionality**:
```bash
# On each validator
snrd keys vrf verify
```
3. **Test encryption features**:
```bash
# Create encrypted record
snrd tx dwn create-record \
--protocol "encrypted-protocol" \
--data "test-data" \
--from validator
```
4. **Monitor for errors**:
```bash
journalctl -u snrd -f | grep -i "vrf\|encryption"
```
## Rollback Procedures
If issues arise during migration:
### Emergency Rollback
1. **Stop affected validators**:
```bash
systemctl stop snrd
```
2. **Disable encryption via governance** (if network is running):
```bash
# Submit emergency proposal
snrd tx gov submit-proposal disable-encryption-proposal.json --expedited
```
3. **Restore from backup**:
```bash
# Stop node
systemctl stop snrd
# Restore backup
tar -xzf validator-backup-YYYYMMDD.tar.gz -C ~/
# Restart
systemctl start snrd
```
4. **Verify recovery**:
```bash
snrd status
```
### Gradual Rollback
If only some validators have issues:
1. Keep VRF keys on working validators
2. Remove VRF keys from problematic validators:
```bash
mv ~/.sonr/vrf_secret.key ~/.sonr/vrf_secret.key.backup
```
3. Disable encryption temporarily
4. Debug issues before retry
## Validation & Testing
### Pre-Migration Testing
Test on a private testnet first:
```bash
# Setup test network
CHAIN_ID="test-migration" make localnet
# Test VRF generation
snrd keys vrf generate --chain-id test-migration
snrd keys vrf verify
# Test with encryption enabled
snrd query dwn params
# Test key rotation
# (trigger validator set change)
```
### Post-Migration Validation
After migration, verify:
1. **All validators have VRF keys**:
```bash
# On each validator
snrd keys vrf show
```
2. **No VRF errors in logs**:
```bash
journalctl -u snrd --since "1 hour ago" | grep -i "vrf" | grep -i "error"
# Should return nothing
```
3. **Encryption working**:
```bash
snrd query dwn params | jq '.params.encryption_enabled'
# Should return: true
```
4. **Key rotation functional**:
```bash
# Check encryption state
snrd query dwn encryption-state
```
## Troubleshooting
### Issue: "VRF keys not loaded"
**Cause**: Keys not generated or file permissions incorrect.
**Fix**:
```bash
# Regenerate keys
snrd keys vrf generate --chain-id <your-chain-id> --force
# Fix permissions
chmod 0600 ~/.sonr/vrf_secret.key
# Verify
snrd keys vrf verify
```
### Issue: "Failed to check and perform key rotation"
**Cause**: Encryption enabled but VRF keys missing on some validators.
**Fix**:
1. Identify validators without VRF keys
2. Temporarily disable encryption
3. Generate VRF keys on all validators
4. Re-enable encryption
### Issue: Network Stalled During Migration
**Cause**: Too many validators offline simultaneously.
**Fix**:
1. Ensure >2/3 voting power online
2. Coordinate restart timing
3. Use smaller migration windows per validator
### Issue: Inconsistent VRF Keys
**Cause**: Different chain-id used during generation.
**Fix**:
```bash
# Check chain-id in genesis
jq '.chain_id' ~/.sonr/config/genesis.json
# Regenerate with correct chain-id
snrd keys vrf generate --chain-id <correct-chain-id> --force
```
## Best Practices
### Before Migration
- ✅ Test on testnet with same topology
- ✅ Backup all validator data
- ✅ Document rollback procedures
- ✅ Prepare monitoring dashboards
- ✅ Schedule during low-traffic period
### During Migration
- ✅ Migrate one validator at a time (gradual)
- ✅ Monitor logs continuously
- ✅ Verify each step before proceeding
- ✅ Keep communication channels open
- ✅ Document any issues encountered
### After Migration
- ✅ Verify all validators functional
- ✅ Test encryption features
- ✅ Monitor performance metrics
- ✅ Update documentation
- ✅ Schedule follow-up verification
## Timeline Recommendations
### Small Network (3-5 validators)
- **Preparation**: 3-5 days
- **Migration**: 1-2 hours
- **Verification**: 1 day
### Medium Network (10-20 validators)
- **Preparation**: 1 week
- **Migration**: 4-6 hours (gradual) or 30 minutes (coordinated)
- **Verification**: 2-3 days
### Large Network (50+ validators)
- **Preparation**: 2-3 weeks
- **Migration**: 1-2 days (gradual) or network upgrade
- **Verification**: 1 week
## Support & Resources
- **VRF Key Management Guide**: `/guides/vrf-key-management`
- **GitHub Issues**: https://github.com/sonr-io/sonr/issues
- **Discord**: Validator support channel
- **Documentation**: https://docs.sonr.io
## Appendix: Automation Script
For networks with many validators, use this automation script:
```bash
#!/bin/bash
# vrf-migration.sh - Automated VRF key migration helper
set -e
CHAIN_ID="${CHAIN_ID:-sonrtest_1-1}"
BACKUP_DIR="${BACKUP_DIR:-$HOME/vrf-backup}"
# Colors for output
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color
log_info() {
echo -e "${GREEN}[INFO]${NC} $1"
}
log_warn() {
echo -e "${YELLOW}[WARN]${NC} $1"
}
log_error() {
echo -e "${RED}[ERROR]${NC} $1"
}
# Backup existing data
backup_validator() {
log_info "Creating backup..."
mkdir -p "$BACKUP_DIR"
tar -czf "$BACKUP_DIR/validator-$(date +%Y%m%d-%H%M%S).tar.gz" \
~/.sonr/config/ \
~/.sonr/data/priv_validator_state.json 2>/dev/null || true
log_info "Backup created at $BACKUP_DIR"
}
# Generate VRF keys
generate_vrf() {
log_info "Generating VRF keys for chain: $CHAIN_ID"
if snrd keys vrf generate --chain-id "$CHAIN_ID"; then
log_info "VRF keys generated successfully"
else
log_error "Failed to generate VRF keys"
exit 1
fi
}
# Verify VRF keys
verify_vrf() {
log_info "Verifying VRF keys..."
if snrd keys vrf verify; then
log_info "VRF keys verified successfully"
else
log_error "VRF key verification failed"
exit 1
fi
}
# Fix permissions
fix_permissions() {
log_info "Fixing VRF key permissions..."
chmod 0600 ~/.sonr/vrf_secret.key
log_info "Permissions set to 0600"
}
# Main migration flow
main() {
log_info "Starting VRF key migration..."
log_info "Chain ID: $CHAIN_ID"
# Backup
backup_validator
# Generate keys
generate_vrf
# Fix permissions
fix_permissions
# Verify
verify_vrf
log_info "Migration completed successfully!"
log_info "Please restart your validator node"
}
# Run migration
main
```
Save and run:
```bash
chmod +x vrf-migration.sh
CHAIN_ID="sonrtest_1-1" ./vrf-migration.sh
```
docs/index.mdx
+272
View File
@@ -0,0 +1,272 @@
---
title: Introduction
description: The peer-to-peer identity and asset management system that makes Web3 as easy as Web2 through DID documents, WebAuthn, and IPFS—providing users with secure, portable decentralized identity
sidebarTitle: "Overview"
icon: "play"
---
# Introduction to Sonr
<Note title="Scope">
This document introduces Sonr's blockchain architecture, core components, and
integration patterns. It covers identity management, authentication, data
sovereignty, and cross-chain operations. This document does not cover
implementation details or code examples—see the Quick Start Guide for hands-on
tutorials.
</Note>
<Note title="Audience">
**Developers** building Web3 applications who want simple integration
patterns. **Validators** interested in securing a next-generation blockchain
network. **Users** seeking sovereign digital identity solutions.
Prerequisites: Basic understanding of web development (HTML/JavaScript) for
developers; blockchain consensus for validators.
</Note>
## Summary
Sonr is a Cosmos SDK blockchain that simplifies Web3 through **Decentralized Identity (DIDs)**, **passwordless authentication (WebAuthn)**, and **user-controlled agents (Vaults)**. Developers integrate crypto features using standard web technologies. Validators secure a network bridging Web2 and Web3. Users gain digital sovereignty without complexity.
## What is Sonr?
Sonr transforms blockchain interaction through four innovations:
1. **W3C-compliant DIDs** replace wallet addresses
2. **WebAuthn** eliminates seed phrases
3. **Personal Vaults** automate blockchain operations
4. **UCAN permissions** prevent unlimited approvals
These components create a system where users onboard in 30 seconds using biometrics, developers add crypto features with HTML forms, and validators earn rewards securing digital sovereignty.
## Why Sonr Matters
### Current Problems
Traditional Web3 forces users to:
- Manage 24-word seed phrases
- Install browser extensions
- Understand gas fees
- Navigate multiple wallets
One mistake loses everything.
### Sonr's Solution
Sonr provides:
- **30-second onboarding** with Face ID or fingerprint
- **No seed phrases** through WebAuthn security
- **No gas fees** for account creation
- **Universal compatibility** across all devices
- **Automatic recovery** via social and biometric methods
## Core Architecture
<CardGroup>
<Card title="Decentralized Identity (DID)" href="/blockchain/modules/did/">
W3C-compliant identity system using WebAuthn for passwordless authentication
</Card>
<Card title="Decentralized Web Nodes (DWN)" href="/blockchain/modules/dwn/">
Personal Vaults acting as user-controlled agents for blockchain interactions
</Card>
<Card title="UCAN Authorization" href="/blockchain/modules/svc/ucan">
Capability-based permissions replacing dangerous unlimited approve patterns
</Card>
<Card title="Service Registry" href="/blockchain/modules/svc/">
Stake-based trust system for service discovery and DNS verification
</Card>
</CardGroup>
## For Developers
### Integration Benefits
Sonr enables crypto features without blockchain knowledge:
- **Use existing skills**: HTML, CSS, JavaScript
- **Zero dependencies**: No SDKs or wallet libraries
- **Progressive enhancement**: Start simple, add features
- **Enterprise ready**: Integrates with existing auth systems
### Simple Payment Example
Transform any HTML form into a crypto payment interface:
```html
<form hx-post="/api/sonr/payment" hx-target="#result">
<input type="email" name="recipient" placeholder="alice@sonr.id" />
<input type="number" name="amount" placeholder="25.00" />
<select name="currency">
<option value="USDC">USDC</option>
<option value="ATOM">ATOM</option>
</select>
<button type="submit">Send Payment</button>
</form>
```
Users approve with biometrics. Vaults handle transactions. No wallet connections required.
### Developer Resources
<CardGroup>
<Card title="Browser Integration" href="/quickstart/browser">
Web browser integration patterns and examples
</Card>
<Card title="Highway Wallet" href="/highway/">
Highway system powering user sovereignty
</Card>
<Card title="Payment Integration" href="/highway/wallets/sending-payments">
Payment integration guide
</Card>
<Card title="Blockchain Modules" href="/blockchain/">
Core blockchain modules and architecture
</Card>
</CardGroup>
## For Validators
### Network Components
Validators secure four critical systems:
<CardGroup>
<Card title="Blockchain Core" href="/blockchain/">
Cosmos SDK with IBC for cross-chain operations
</Card>
<Card title="Token Economics" href="/blockchain/token/">
Tokenomics, staking, and governance
</Card>
<Card title="Highway Proxy" href="/highway/">
HTTP bridge supporting WebAuthn authentication
</Card>
<Card title="Validator Setup" href="/quickstart/validators">
Validator node setup and operations
</Card>
</CardGroup>
### Validator Operations
Validators perform five key functions:
1. **Validate identities**: Process DID operations and WebAuthn credentials
2. **Execute Vaults**: Run capability delegations and revocations
3. **Bridge chains**: Process IBC and InterchainAccount transactions
4. **Verify services**: Validate DNS ownership and registrations
5. **Coordinate MPC**: Participate in multi-party key management
### Economic Incentives
- **Block rewards**: Earn from transaction fees and inflation
- **Service fees**: Share revenue from registrations
- **MEV protection**: Built-in maximal extractable value prevention
- **Sustainable model**: Long-term network health design
## Key Concepts
### Identity Management
<CardGroup>
<Card title="Identity System" href="/blockchain/modules/did/">
W3C DIDs with WebAuthn for digital sovereignty
</Card>
<Card title="DID Module" href="/blockchain/modules/did/">
Blockchain implementation of identity management
</Card>
</CardGroup>
### Data Sovereignty
<CardGroup>
<Card title="DWN Module" href="/blockchain/modules/dwn/">
Personal Vaults for user-controlled data and agents
</Card>
<Card title="Blockchain Network" href="/blockchain/network">
Network architecture and specifications
</Card>
</CardGroup>
### Authorization System
<CardGroup>
<Card title="UCAN Module" href="/blockchain/modules/svc/ucan">
Capability-based permissions for secure delegation
</Card>
<Card title="Service Module" href="/blockchain/modules/svc/">
Registration, verification, and trust management
</Card>
</CardGroup>
### Cross-Chain Features
<CardGroup>
<Card title="Blockchain Network" href="/blockchain/network">
Network architecture and cross-chain features
</Card>
<Card title="Payment Handler" href="/highway/wallets/sending-payments">
W3C API for seamless crypto payments
</Card>
</CardGroup>
## Getting Started
### Developers
Build Web3 applications without blockchain complexity:
<CardGroup>
<Card title="Quick Start" href="/quickstart/">
Create your first Sonr application in 10 minutes
</Card>
<Card title="Browser Integration" href="/quickstart/browser">
Real-world integration patterns for web applications
</Card>
<Card title="CLI Tools" href="/quickstart/cli">
Command line tools and utilities
</Card>
</CardGroup>
### Validators
Secure the future of digital sovereignty:
<CardGroup>
<Card title="Node Setup" href="/quickstart/validators">
Complete validator installation guide
</Card>
<Card title="Token Economics" href="/blockchain/token/">
Token distribution, staking, and governance
</Card>
<Card title="Security" href="/reference/security/">
Security practices and compliance
</Card>
</CardGroup>
### Users
Experience true digital ownership:
<CardGroup>
<Card title="Create Identity" href="/blockchain/modules/did/onboarding">
30-second setup with biometric authentication
</Card>
<Card title="Use Your Vault" href="/blockchain/modules/dwn/">
Master your personal Web3 agent
</Card>
<Card title="Security Guide" href="/reference/security/">
Privacy and sovereignty protection
</Card>
</CardGroup>
## Next Steps
<Note title="Ready to Build?" type="success">
**Developers**: Start with the [Quick Start Guide](/quickstart/) to build your first Sonr application.
**Validators**: Follow the [Node Setup Guide](/quickstart/validators) to join the network.
**Users**: [Create your identity](/blockchain/modules/did/onboarding) in under 30 seconds.
</Note>
Explore the concepts above or dive into specific topics using the navigation menu. Join us in building the sovereign internet where identity belongs to individuals, not platforms.
docs/quickstart/browser.mdx
+191
View File
@@ -0,0 +1,191 @@
---
title: Getting Started with Browser/ESM
description: A quick start guide for using Sonr in web browsers with WebAuthn integration
sidebarTitle: Browser Quickstart
icon: "globe"
---
This guide will walk you through creating a simple web application that interacts with the Sonr network directly from the browser. We will use the Sonr JavaScript SDK to create a new user identity, claim a Vault, and send a transaction.
## Prerequisites
- A local Sonr network running. See the [Validator Setup Guide](/quickstart/validators) for instructions
- A modern web browser with WebAuthn support (Chrome, Firefox, Safari, Edge)
## 1. Project Setup
<Steps>
<Step>
### Create an HTML File
Create a new `index.html` file and add the following basic structure:
```html
<!DOCTYPE html>
<html>
<head>
<title>Sonr Browser Quickstart</title>
<script type="module" src="app.js"></script>
</head>
<body>
<h1>Sonr Browser Quickstart</h1>
<button id="create-identity">Create Identity</button>
<div id="output"></div>
</body>
</html>
```
</Step>
<Step>
### Create a JavaScript File
Create a new `app.js` file in the same directory. This is where we will write our application logic.
</Step>
<Step>
### Install the Sonr SDK
For this quickstart, we will use the Sonr SDK from a CDN. Add the following script tag to the `<head>` of your `index.html` file:
```html
<script type="module">
import { Sonr, WebAuthn } from "https://cdn.jsdelivr.net/npm/@sonr/sdk";
window.Sonr = Sonr;
window.WebAuthn = WebAuthn;
</script>
```
</Step>
</Steps>
## 2. Creating an Identity
Now, let's add the logic to create a new user identity and claim a Vault.
<Steps>
<Step>
### Add Event Listener
In `app.js`, add an event listener to the "Create Identity" button:
```javascript
document
.getElementById("create-identity")
.addEventListener("click", async () => {
const output = document.getElementById("output");
output.innerHTML = "Creating identity...";
try {
// Code to create identity will go here
} catch (error) {
output.innerHTML = `Error: ${error.message}`;
}
});
```
</Step>
<Step>
### Implement Identity Creation
Inside the event listener, use the `WebAuthn.createCredential` method to create a new WebAuthn credential and the `Sonr.claimVault` method to claim a new Vault on the network.
```javascript
// Inside the try block
const credential = await WebAuthn.createCredential({
rp: { name: "Sonr Quickstart" },
user: {
id: new Uint8Array(16), // Should be a unique user ID
name: "user@example.com",
displayName: "Test User",
},
});
output.innerHTML = `Credential created: ${credential.id}`;
const sonr = new Sonr({ httpUrl: "http://localhost:1317" });
const vault = await sonr.claimVault(credential);
output.innerHTML = `Vault claimed! DID: ${vault.did}`;
```
<Note type="warning">
In a real application, the user ID should be a unique and stable identifier
for the user, not a random value.
</Note>
</Step>
</Steps>
## 3. Running the Application
To run the application, you need a simple web server. You can use the `http-server` package for this.
```bash
# Install http-server
npm install -g http-server
# Start the server
http-server
```
Now, open your browser and navigate to `http://localhost:8080`. When you click the "Create Identity" button, your browser will prompt you to create a new passkey using your device's biometrics or a security key.
## 4. Sending a Transaction
Once you have a Vault, you can use it to send transactions.
<Steps>
<Step>
### Add a Send Button
Add a new button to your `index.html` file:
```html
<button id="send-transaction" disabled>Send Transaction</button>
```
</Step>
<Step>
### Implement Transaction Sending
In `app.js`, add an event listener to the new button. This will use the `sonr.send` method to send a transaction.
```javascript
let vaultInstance;
// After claiming the vault...
vaultInstance = vault;
document.getElementById("send-transaction").disabled = false;
document
.getElementById("send-transaction")
.addEventListener("click", async () => {
const output = document.getElementById("output");
output.innerHTML = "Sending transaction...";
try {
const result = await vaultInstance.send({
to: "snr1..._recipient_address_...",
amount: "1000000usnr", // 1 SNR
});
output.innerHTML = `Transaction successful! TxHash: ${result.txhash}`;
} catch (error) {
output.innerHTML = `Error: ${error.message}`;
}
});
```
</Step>
</Steps>
## Next Steps
Congratulations! You have successfully created a web application that interacts with the Sonr network. From here, you can explore more advanced features:
- **Service Registration**: Register your application as a trusted service on the network
- **UCAN Authorization**: Request and manage user permissions for your application
- **Cross-Chain Operations**: Interact with other blockchains through IBC
docs/quickstart/golang.mdx
+521
View File
@@ -0,0 +1,521 @@
---
title: Getting Started with Golang
description: A quick start guide for building applications with Sonr using the Go Client SDK
sidebarTitle: Golang Quickstart
icon: "golang"
---
This guide provides a walkthrough for setting up a Go project to interact with the Sonr network using the official Go Client SDK. You will learn how to configure the client, manage keys, query the blockchain, send transactions, and use advanced features like WebAuthn gasless transactions.
## Prerequisites
- A local Sonr network running. See the [Validator Setup Guide](/quickstart/validators) for instructions
- Go version 1.24 or higher
## 1. Project Setup
<Steps>
<Step>
### Initialize a Go Module
Create a new directory for your project and initialize a Go module:
```bash
mkdir sonr-go-quickstart
cd sonr-go-quickstart
go mod init github.com/your-username/sonr-go-quickstart
```
</Step>
<Step>
### Add the Sonr Client SDK Dependency
Add the Sonr Client SDK to your project's dependencies:
```bash
go get github.com/sonr-io/sonr/client
```
</Step>
</Steps>
## 2. Client Configuration and Setup
Let's set up the Sonr client with proper configuration and key management.
<Steps>
<Step>
### Create the Main File
Create a new file named `main.go`.
</Step>
<Step>
### Initialize the Client
Add the following code to `main.go` to initialize the Sonr client:
```go
package main
import (
"context"
"fmt"
"log"
"google.golang.org/grpc"
"google.golang.org/grpc/credentials/insecure"
"github.com/sonr-io/sonr/client/config"
"github.com/sonr-io/sonr/client/keys"
"github.com/sonr-io/sonr/client/sonr"
"github.com/sonr-io/sonr/client/tx"
)
func main() {
// Use local network configuration
cfg := config.LocalNetwork()
// Establish gRPC connection
conn, err := grpc.Dial(
cfg.GRPC,
grpc.WithTransportCredentials(insecure.NewCredentials()),
)
if err != nil {
log.Fatal("Failed to connect:", err)
}
defer conn.Close()
// Create the Sonr client
client, err := sonr.NewClient(&cfg, conn)
if err != nil {
log.Fatal("Failed to create client:", err)
}
fmt.Println("Sonr client initialized successfully!")
fmt.Printf("Connected to: %s\n", cfg.ChainID)
}
```
</Step>
<Step>
### Create a Keyring Manager
Add key management to handle wallet operations:
```go
// Initialize keyring manager (using test backend for development)
keyringManager, err := keys.NewKeyringManager(
"test", // backend: test, file, os
".sonr-keys", // directory for keys
cfg.ChainID, // chain ID
)
if err != nil {
log.Fatal("Failed to create keyring:", err)
}
// Create a new wallet
walletIdentity, mnemonic, err := keyringManager.CreateWallet(
context.Background(),
"my-wallet", // wallet name
"", // passphrase (empty for test backend)
)
if err != nil {
log.Fatal("Failed to create wallet:", err)
}
fmt.Printf("Wallet created!\n")
fmt.Printf("Address: %s\n", walletIdentity.Address)
fmt.Printf("DID: %s\n", walletIdentity.DID)
fmt.Printf("Mnemonic: %s\n", mnemonic)
```
<Note type="warning">
**Important**: In production, use secure keyring backends like "os" or "file" with proper passphrase protection. Never expose mnemonics in your code.
</Note>
</Step>
</Steps>
## 3. Querying the Blockchain
Now, let's query the blockchain using the unified query client.
<Steps>
<Step>
### Create a Query Client
Add the query client to your application:
```go
import (
"github.com/sonr-io/sonr/client/query"
)
// Create query client
queryClient, err := query.NewQueryClient(conn, &cfg)
if err != nil {
log.Fatal("Failed to create query client:", err)
}
```
</Step>
<Step>
### Query Account Balance
Query an account's balance:
```go
// Query account balance
address := walletIdentity.Address // or any other address
balance, err := queryClient.Balance(
context.Background(),
address,
cfg.StakingDenom, // "usnr"
)
if err != nil {
log.Printf("Failed to query balance: %v", err)
} else {
fmt.Printf("Balance for %s: %s %s\n",
address,
balance.Balance.Amount.String(),
balance.Balance.Denom,
)
}
// Query all balances for an account
allBalances, err := queryClient.AllBalances(
context.Background(),
address,
nil, // pagination
)
if err != nil {
log.Printf("Failed to query all balances: %v", err)
} else {
fmt.Printf("All balances: %v\n", allBalances.Balances)
}
```
</Step>
<Step>
### Query Module-Specific Data
Query DID documents and other module data:
```go
import (
"github.com/sonr-io/sonr/client/modules/did"
)
// Create DID module client
didClient := did.NewDIDClient()
// Query DID document (if exists)
didID := "did:sonr:example123"
didDoc, err := queryClient.GetDID(context.Background(), didID)
if err != nil {
log.Printf("DID not found: %v", err)
} else {
fmt.Printf("DID Document: %+v\n", didDoc)
}
// List all DIDs with pagination
didList, err := queryClient.ListDIDs(
context.Background(),
&query.ListOptions{
Limit: 10,
Offset: 0,
},
)
if err != nil {
log.Printf("Failed to list DIDs: %v", err)
} else {
fmt.Printf("Found %d DIDs\n", len(didList.DIDs))
}
```
</Step>
</Steps>
## 4. Building and Broadcasting Transactions
Let's build and broadcast transactions using the transaction builder.
<Steps>
<Step>
### Create a Transaction Builder
Initialize the transaction builder with gas estimation:
```go
// Create transaction builder
txBuilder, err := tx.NewTxBuilder(&cfg, conn)
if err != nil {
log.Fatal("Failed to create tx builder:", err)
}
// Create broadcaster
broadcaster, err := tx.NewBroadcaster(&cfg, conn)
if err != nil {
log.Fatal("Failed to create broadcaster:", err)
}
// Create gas estimator
gasEstimator := tx.NewGasEstimator(conn, &cfg)
```
</Step>
<Step>
### Send Tokens Between Accounts
Build and broadcast a bank send transaction:
```go
import (
sdk "github.com/cosmos/cosmos-sdk/types"
banktypes "github.com/cosmos/cosmos-sdk/x/bank/types"
)
// Create a second wallet to receive funds
receiver, _, err := keyringManager.CreateWallet(
context.Background(),
"receiver-wallet",
"",
)
if err != nil {
log.Fatal("Failed to create receiver wallet:", err)
}
// Create send message
amount := sdk.NewCoins(sdk.NewInt64Coin("usnr", 1000000)) // 1 SNR
sendMsg := &banktypes.MsgSend{
FromAddress: walletIdentity.Address,
ToAddress: receiver.Address,
Amount: amount,
}
// Build transaction
txBuilder = txBuilder.
AddMessage(sendMsg).
WithMemo("Test transaction").
WithGasLimit(200000)
// Estimate gas
gasEstimate, err := gasEstimator.EstimateGas(
context.Background(),
[]sdk.Msg{sendMsg},
)
if err != nil {
log.Printf("Gas estimation failed: %v", err)
} else {
fmt.Printf("Estimated gas: %d\n", gasEstimate.GasLimit)
txBuilder = txBuilder.WithGasLimit(gasEstimate.GasLimit)
}
// Calculate and set fee
fee := gasEstimator.CalculateFee(
gasEstimate.GasLimit,
cfg.GasPrice,
cfg.StakingDenom,
)
txBuilder = txBuilder.WithFee(fee)
// Sign the transaction
signedTx, err := txBuilder.Sign(context.Background(), keyringManager)
if err != nil {
log.Fatal("Failed to sign transaction:", err)
}
// Broadcast the transaction
result, err := broadcaster.BroadcastTx(context.Background(), signedTx)
if err != nil {
log.Fatal("Failed to broadcast transaction:", err)
}
fmt.Printf("Transaction successful!\n")
fmt.Printf("TxHash: %s\n", result.TxHash)
fmt.Printf("Height: %d\n", result.Height)
fmt.Printf("Gas Used: %d\n", result.GasUsed)
```
</Step>
</Steps>
## 5. WebAuthn Gasless Transactions (Advanced)
Sonr supports gasless WebAuthn registration, allowing users to onboard without holding tokens.
<Steps>
<Step>
### Initialize WebAuthn Client
Set up the WebAuthn client for gasless operations:
```go
import (
"github.com/sonr-io/sonr/client/auth"
)
// Create WebAuthn client
webauthnClient := auth.NewWebAuthnClient(
keyringManager,
"localhost", // Relying Party ID
"Sonr Local", // Relying Party Name
)
// Create gasless transaction manager
gaslessManager := auth.NewGaslessTransactionManager(
txBuilder,
broadcaster,
&cfg,
)
// Create WebAuthn gasless client
gaslessClient := auth.NewWebAuthnGaslessClient(
webauthnClient,
gaslessManager,
&cfg,
)
```
</Step>
<Step>
### Initiate Gasless Registration
Start a gasless WebAuthn registration:
```go
// Begin gasless registration
registrationResult, err := gaslessClient.RegisterGasless(
context.Background(),
"alice", // username
"Alice Smith", // display name
)
if err != nil {
log.Fatal("Failed to initiate registration:", err)
}
fmt.Printf("Registration initiated!\n")
fmt.Printf("Gasless eligible: %v\n", registrationResult.GaslessEligible)
fmt.Printf("Estimated gas: %d\n", registrationResult.EstimatedGas)
// The challenge would be sent to a browser for completion
// In a real application, you'd handle the browser response
```
</Step>
<Step>
### Check Gasless Eligibility
Verify if a transaction is eligible for gasless processing:
```go
// Check if messages are eligible for gasless
msgs := []sdk.Msg{
&didtypes.MsgRegisterWebAuthnCredential{
Controller: "sonr1...",
Username: "alice",
},
}
isEligible := gaslessManager.IsEligibleForGasless(msgs)
fmt.Printf("Transaction eligible for gasless: %v\n", isEligible)
// Estimate gas for gasless transaction
gasNeeded := gaslessManager.EstimateGaslessGas(
"/did.v1.MsgRegisterWebAuthnCredential",
)
fmt.Printf("Gas needed for gasless WebAuthn: %d\n", gasNeeded)
```
</Step>
</Steps>
## 6. Working with DID Module
Create and manage decentralized identities:
<Steps>
<Step>
### Create a DID Document
```go
import (
didtypes "github.com/sonr-io/sonr/x/did/types"
)
// Create DID document
didDoc := &didtypes.DidDocument{
Id: "did:sonr:" + walletIdentity.Address,
Controller: walletIdentity.Address,
VerificationMethod: []*didtypes.VerificationMethod{
{
Id: "did:sonr:" + walletIdentity.Address + "#key-1",
VerificationMethodKind: didtypes.VerificationMethodKind_Ed25519VerificationKey2020,
Controller: "did:sonr:" + walletIdentity.Address,
PublicKeyMultibase: "z6MkhaXgBZD...", // Your public key
},
},
Service: []*didtypes.Service{
{
Id: "did:sonr:" + walletIdentity.Address + "#dwn",
ServiceKind: didtypes.ServiceKind_DecentralizedWebNode,
SingleEndpoint: "https://dwn.example.com",
},
},
}
// Create the message
createDIDMsg, err := didClient.CreateDID(
walletIdentity.Address,
didDoc,
)
if err != nil {
log.Fatal("Failed to create DID message:", err)
}
// Add to transaction and broadcast
txBuilder = txBuilder.
ClearMessages().
AddMessage(createDIDMsg).
WithMemo("Create DID")
// Sign and broadcast as shown earlier
```
</Step>
</Steps>
## Next Steps
This quickstart has covered the fundamentals of the Sonr Go Client SDK:
- **Client Configuration**: Setting up connections and network configurations
- **Key Management**: Creating and managing wallets with the keyring
- **Querying**: Reading blockchain state and module data
- **Transactions**: Building, signing, and broadcasting transactions
- **Gas Estimation**: Calculating optimal gas limits and fees
- **WebAuthn**: Gasless onboarding with WebAuthn credentials
- **DID Module**: Creating decentralized identities
### Advanced Topics to Explore:
- **DWN Module**: Manage decentralized web nodes and data records
- **Service Module**: Register and verify services with domain verification
- **UCAN Integration**: Implement capability-based authorization
- **Multi-signature**: Create and manage multi-sig accounts
- **IBC Transfers**: Cross-chain token transfers
- **Custom Modules**: Interact with your own custom modules
### Useful Resources:
- [Client SDK API Reference](https://pkg.go.dev/github.com/sonr-io/sonr/client)
- [Cosmos SDK Documentation](https://docs.cosmos.network)
- [Sonr GitHub Repository](https://github.com/sonr-io/sonr)
docs/quickstart/react.mdx
+190
View File
@@ -0,0 +1,190 @@
---
title: Getting Started with ReactJS
description: A quick start guide for building applications with Sonr using JavaScript and TypeScript
sidebarTitle: React Quickstart
icon: "react"
---
This guide will show you how to set up a Node.js project with TypeScript and use the Sonr SDK to interact with the Sonr network.
## Prerequisites
- A local Sonr network running. See the [Validator Setup Guide](/quickstart/validators) for instructions
- Node.js version 16 or higher
- npm or yarn
## 1. Project Setup
<Steps>
<Step>
### Initialize a New Project
Create a new directory for your project and initialize it with npm:
```bash
mkdir sonr-ts-quickstart
cd sonr-ts-quickstart
npm init -y
```
</Step>
<Step>
### Install Dependencies
Install the Sonr SDK and TypeScript:
```bash
npm install @sonr/sdk typescript ts-node @types/node
```
</Step>
<Step>
### Configure TypeScript
Create a `tsconfig.json` file in your project root with the following configuration:
```json
{
"compilerOptions": {
"target": "es2020",
"module": "commonjs",
"esModuleInterop": true,
"forceConsistentCasingInFileNames": true,
"strict": true,
"skipLibCheck": true
}
}
```
</Step>
</Steps>
## 2. Creating a Wallet
Now, let's create a new TypeScript file and add the logic to create a new Sonr wallet.
<Steps>
<Step>
### Create the Main File
Create a new file named `index.ts`.
</Step>
<Step>
### Implement Wallet Creation
Add the following code to `index.ts` to create a new wallet and log its address and mnemonic:
```typescript
import { Sonr } from "@sonr/sdk";
async function main() {
console.log("Creating a new Sonr wallet...");
const sonr = new Sonr({ httpUrl: "http://localhost:1317" });
const wallet = await sonr.createWallet();
console.log(`Wallet created!`);
console.log(`Address: ${wallet.address}`);
console.log(`Mnemonic: ${wallet.mnemonic}`);
}
main().catch(console.error);
```
<Note type="warning">
**Important**: In a real application, you must store the mnemonic securely.
Never expose it in client-side code.
</Note>
</Step>
<Step>
### Run the Script
Execute the script using `ts-node`:
```bash
npx ts-node index.ts
```
You should see the new wallet's address and mnemonic printed to the console.
</Step>
</Steps>
## 3. Querying the Blockchain
Let's query the blockchain to get the balance of our new wallet.
<Steps>
<Step>
### Get Account Balance
Modify your `index.ts` file to query the account balance after creating the wallet. You will need to fund this account from the localnet faucet for it to have a balance.
```typescript
// ... after creating the wallet
console.log("Querying account balance...");
// The localnet validator has funds, so we'll use its address for the query
const validatorAddress = "snr1..._validator_address_..."; // Replace with the actual validator address from your localnet
const balance = await sonr.getAccountBalance(validatorAddress);
console.log(`Balance for ${validatorAddress}:`, balance);
```
</Step>
<Step>
### Run the Script Again
Run the script to see the account balance:
```bash
npx ts-node index.ts
```
</Step>
</Steps>
## 4. Sending a Transaction
Finally, let's send a transaction from one account to another.
<Steps>
<Step>
### Implement Transaction Sending
For this step, you will need two wallets. You can create a second one using the same `createWallet` method. Ensure both wallets have funds from the localnet faucet.
```typescript
// ... inside your main function
const wallet1 = await sonr.createWallet(); // Fund this from the faucet
const wallet2 = await sonr.createWallet();
console.log(`Sending 1 SNR from ${wallet1.address} to ${wallet2.address}`);
const result = await wallet1.send({
to: wallet2.address,
amount: "1000000usnr", // 1 SNR
});
console.log(`Transaction successful! TxHash: ${result.txhash}`);
```
</Step>
</Steps>
## Next Steps
This quickstart has shown you the basics of interacting with the Sonr network using our TypeScript SDK. You can now explore more advanced topics:
- **Service Registration**: Register your application as a trusted service
- **UCAN Authorization**: Implement capability-based permissions
- **Smart Contract Interaction**: Call and query smart contracts on the Sonr network
docs/reference/architecture/decentralized-authentication.mdx
+191
View File
@@ -0,0 +1,191 @@
---
title: "Migrating from Centralized to Decentralized Authentication"
description: "A comprehensive guide to migrating from centralized 8787 endpoints to decentralized OIDC authentication with WebAuthn"
sidebarTitle: "Decentralized Authentication"
icon: "key"
---
# Migrating from Centralized to Decentralized Authentication
## Overview
Sonr is transitioning from a centralized authentication model using 8787 endpoints to a fully decentralized, privacy-preserving authentication system leveraging OpenID Connect (OIDC), Self-Issued OpenID Provider (SIOP), and WebAuthn technologies.
### Key Improvements
- **Decentralization**: Move from centralized identity management to self-sovereign identity
- **WebAuthn Integration**: Hardware-backed, phishing-resistance authentication
- **Gasless Onboarding**: Zero-cost user registration and transactions
- **Automatic Vault Creation**: Seamless user experience with instant identity setup
- **Enhanced Privacy**: DID-based authentication with verifiable presentations
## Architecture Comparison
### Old Architecture: Centralized 8787 Endpoints
- Centralized authentication server
- Fixed credential storage
- Limited authentication methods
- Higher security risks
### New Architecture: Decentralized OIDC Provider
```mermaid
graph TD
A[User Device] --> B{WebAuthn Registration}
B --> |Credential Generation| C[Blockchain Bridge]
C --> |Broadcast Credential| D[Sonr Blockchain]
D --> |Create DID| E[User's Decentralized Identity]
E --> |SIOP Flow| F[OIDC Provider]
F --> |Verifiable Presentation| G[Service Provider]
```
## Migration Steps
### 1. Prerequisites
- Go 1.24.1+
- Cosmos SDK v0.50.14
- WebAuthn-compatible browser/device
- Updated Sonr SDK
### 2. Configuration Changes
#### Environment Variables
<CodeGroup>
```bash title="Old Configuration"
# Centralized auth endpoints
AUTH_ENDPOINT=https://8787.sonr.io/auth
AUTH_CLIENT_ID=legacy-client-id
```
```bash title="New Configuration"
# Decentralized OIDC configuration
OIDC_PROVIDER_URL=https://oidc.sonr.network
WEBAUTHN_ORIGIN=https://your-app.com
DID_RESOLVER_URL=https://did.sonr.network
```
</CodeGroup>
### 3. Endpoint Migration
| Old Endpoint | New Endpoint | Changes |
| ---------------- | -------------------- | ----------------------- |
| `/auth/login` | `/oidc/authorize` | OIDC authorization flow |
| `/auth/register` | `/webauthn/register` | WebAuthn registration |
| `/auth/token` | `/oidc/token` | Token issuance via SIOP |
### 4. API Changes
#### Request Format
<CodeGroup>
```json title="Legacy Request"
{
"username": "user@example.com",
"password": "legacy-password"
}
```
```json title="New WebAuthn Request"
{
"challenge": "base64-encoded-challenge",
"attestation": {
"type": "public-key",
"id": "credential-id",
"rawId": "base64-encoded-raw-credential",
"response": {
"clientDataJSON": "...",
"attestationObject": "..."
}
}
}
```
</CodeGroup>
### 5. WebAuthn Integration
#### Registration Flow
1. Generate registration challenge
2. Create WebAuthn credential
3. Broadcast credential to blockchain
4. Automatically create user vault
5. Issue decentralized identifier (DID)
#### Code Example
```go title="WebAuthn Registration Handler"
func (s *Server) HandleWebAuthnRegistration(w http.ResponseWriter, r *http.Request) {
// 1. Validate WebAuthn attestation
credential, err := s.webAuthnService.VerifyRegistration(attestationData)
// 2. Broadcast to blockchain
didDoc, err := s.blockchainBridge.CreateDID(credential)
// 3. Create user vault
vault, err := s.vaultService.CreateVault(didDoc)
// 4. Issue OIDC token
token := s.oidcService.IssueToken(didDoc)
}
```
### 6. SIOP (Self-Issued OpenID Provider)
#### Key Concepts
- Verifiable Presentations
- Decentralized Identifiers (DIDs)
- User-controlled authentication
### 7. Error Handling
#### Migration Errors
| Error Code | Description | Mitigation |
| ------------------------ | ---------------------- | -------------------- |
| `AUTH_LEGACY_DEPRECATED` | Legacy auth method | Upgrade client |
| `WEBAUTHN_UNSUPPORTED` | Device incompatibility | Use alternative auth |
| `DID_RESOLUTION_FAILED` | Identity verification | Retry registration |
### 8. Testing Migration
```bash
# Validate WebAuthn registration
sonr webauthn test-registration
# Verify OIDC provider
sonr oidc validate-provider
# Check DID resolution
sonr did resolve did:sonr:example
```
### 9. Breaking Changes
- Legacy password authentication removed
- Token format changed to JWT with DID claims
- New client libraries required
- WebAuthn mandatory for registration
## Rollback Procedure
If issues arise:
1. Maintain legacy user mappings
2. Provide fallback authentication
3. Gradual, opt-in migration
## Conclusion
This migration represents a significant leap in authentication security and user privacy. By adopting WebAuthn, SIOP, and blockchain-backed identities, we're creating a more robust, user-controlled authentication ecosystem.
## Support
- [Sonr Developer Docs](/docs)
- [WebAuthn Specification](https://www.w3.org/TR/webauthn-2/)
- [OIDC Community](https://openid.net/developers/specs/)
docs/reference/architecture/decentralized-identity.mdx
+129
View File
@@ -0,0 +1,129 @@
---
title: "DID Generation and Management"
description: "Learn how to generate and manage Decentralized Identifiers (DIDs) using advanced crypto interfaces"
sidebarTitle: "Identity Generation"
icon: "signature"
---
# DID Generation Patterns
The Sonr project provides a robust and flexible DID (Decentralized Identifier) generation system supporting multiple key types and cryptographic methods.
## Supported Key Types
The `didkey.go` interface supports the following key types:
- RSA Public Keys
- Ed25519 Public Keys
- Secp256k1 Public Keys
## Basic DID Generation
### Creating a DID from a Public Key
```go
import (
"github.com/libp2p/go-libp2p/core/crypto"
"github.com/sonr-io/sonr/crypto/keys"
)
// Generate a new key pair
privateKey, publicKey, err := crypto.GenerateKeyPair(crypto.Ed25519, -1)
// Create a DID
did, err := keys.NewDID(publicKey)
```
### Parsing an Existing DID
```go
// Parse a DID string
did, err := keys.Parse("did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGTsyDFWYviJr4")
```
## Advanced DID Operations
### Address Derivation
```go
// Get a blockchain-compatible address from a DID
address, err := did.Address()
```
### Compressed Public Key Retrieval
```go
// Get a compressed public key (for Secp256k1)
compressedPubKey, err := did.CompressedPubKey()
```
## MPC Enclave DID Generation
For MPC (Multi-Party Computation) enclaves, use a specialized method:
```go
// Create a DID from MPC enclave public key bytes
did, err := keys.NewFromMPCPubKey(enclavePublicKeyBytes)
```
## DID Validation
```go
// Validate a DID format
err := keys.ValidateFormat("did:key:example123")
```
## Multicodec Support
The library supports various multicodec prefixes for different key types:
- RSA: `0x1205`
- Ed25519: `0xed`
- Secp256k1: `0xe7`
## Security Considerations
- Always generate keys using cryptographically secure methods
- Validate DIDs before using them in critical operations
- Use the appropriate key type for your security requirements
## Example: Complete DID Workflow
```go
package main
import (
"fmt"
"github.com/libp2p/go-libp2p/core/crypto"
"github.com/sonr-io/sonr/crypto/keys"
)
func main() {
// Generate a new key pair
privateKey, publicKey, err := crypto.GenerateKeyPair(crypto.Ed25519, -1)
if err != nil {
panic(err)
}
// Create a DID
did, err := keys.NewDID(publicKey)
if err != nil {
panic(err)
}
// Get the DID string
didString := did.String()
fmt.Println("Generated DID:", didString)
// Derive blockchain address
address, err := did.Address()
if err != nil {
panic(err)
}
fmt.Println("Blockchain Address:", address)
}
```
## Compatibility and Interoperability
The Sonr DID implementation follows the W3C DID specification, ensuring broad compatibility with other decentralized identity systems.
docs/reference/architecture/decentralized-web-node.mdx
+155
View File
@@ -0,0 +1,155 @@
---
title: "DWN Plugin Architecture"
description: "Deep dive into the Decentralized Web Node (DWN) plugin system and integration"
sidebarTitle: "WASM Architecture"
icon: "puzzle"
---
# DWN Plugin Architecture
The Sonr project implements a flexible and secure plugin system for Decentralized Web Nodes (DWN), enabling modular and extensible functionality.
## Overview
The plugin architecture is designed to:
- Support dynamic loading of WebAssembly (WASM) plugins
- Provide a standardized interface for plugin interactions
- Enable secure, isolated execution of plugins
## Core Components
### Plugin Manager
The `PluginManager` manages plugin lifecycle and interactions:
```go
type PluginManager struct {
plugins map[string]Plugin
actors map[string]Actor
}
type Plugin interface {
Initialize(config map[string]any) error
Execute(method string, payload []byte) ([]byte, error)
Close() error
}
```
### Plugin Configuration
Plugins are configured through a structured configuration:
```go
type PluginConfig struct {
ID string // Unique plugin identifier
Type string // Plugin type (e.g., "motor", "crypto")
Path string // WASM module path
Environment map[string]any // Plugin-specific environment variables
}
```
## Loading and Initializing Plugins
### Basic Plugin Loading
```go
func (pm *PluginManager) LoadPlugin(config PluginConfig) error {
// Load WASM module
module, err := extism.Load(config.Path)
if err != nil {
return err
}
// Initialize plugin
plugin := &WASMPlugin{
module: module,
config: config,
}
// Store in plugin registry
pm.plugins[config.ID] = plugin
}
```
### Actor-Based Plugin Management
```go
func (pm *PluginManager) CreateActor(pluginID string) (*Actor, error) {
plugin, exists := pm.plugins[pluginID]
if !exists {
return nil, errors.New("plugin not found")
}
actor := NewActor(plugin)
pm.actors[actor.ID] = actor
return actor, nil
}
```
## Plugin Execution Workflow
1. Plugin is loaded from WASM module
2. Configuration is applied
3. Plugin is initialized
4. Specific methods can be invoked through a standardized interface
### Example Plugin Execution
```go
func ExecutePluginMethod(pluginID, method string, payload []byte) ([]byte, error) {
plugin := pluginManager.plugins[pluginID]
return plugin.Execute(method, payload)
}
```
## Configuration and Environment
### Plugin Environment Variables
```json
{
"motor_plugin": {
"enclave_config": { ... },
"chain_id": "sonr-testnet-1",
"log_level": "debug"
}
}
```
## Error Handling and Logging
```go
type PluginError struct {
Code string
Message string
Details map[string]any
}
```
## Security Considerations
- WASM plugins run in an isolated sandbox
- Limited access to system resources
- Runtime restrictions prevent malicious behavior
- Cryptographic verification of plugin modules
## Plugin Types
1. **Crypto Plugins**: Cryptographic operations
2. **Motor Plugins**: MPC and token management
3. **DID Plugins**: Decentralized Identity operations
4. **Custom Plugins**: Application-specific extensions
## Best Practices
- Keep plugins small and focused
- Use standardized interfaces
- Implement comprehensive error handling
- Validate all plugin inputs
- Monitor plugin performance
## Advanced Configuration
For advanced plugin configuration and deployment, refer to the [PDK Configuration Guide](/blockchain/modules/dwn/configuration).
docs/reference/architecture/delegated-proof-of-stake.mdx
+31
View File
@@ -0,0 +1,31 @@
---
title: Delegated Proof of Stake (DPoS)
description: A decentralized, secure, and efficient consensus mechanism.
---
Sonr leverages a Delegated Proof of Stake (DPoS) mechanism to optimize network security and user participation. DPoS imposes an opportunity cost for malicious behavior through slashing, but it also presents challenges that must be addressed for a sustainable design.
## Challenges in Staking Mechanisms
- **Token Value**: The token must have intrinsic value to incentivize staking.
- **Wealth Concentration**: Staking can give an outsized advantage to wealthy users.
- **Coordination Problems**: Staking mechanisms can be gamed by coordinated actors.
## Sonr's Approach to DPoS
We have designed our staking mechanism to address these challenges and create a sustainable and equitable system:
<CardGroup>
<Card title="Low Barrier to Entry">
The upfront capital required to stake is designed to not significantly
discourage participation.
</Card>
<Card title="Slashing for Malice">
If a stakeholder group makes decisions that materially harm the network,
their stake is slashed.
</Card>
<Card title="Incentivizing Positive Growth">
Stakeholders can make decisions that positively impact the future network
health and token price, promoting long-term growth.
</Card>
</CardGroup>
docs/reference/architecture/inter-blockchain-communication.mdx
+29
View File
@@ -0,0 +1,29 @@
---
title: Network Architecture
description: A detailed look at Sonr's three-tier system design.
---
Our incorporation of embedded light nodes signifies a strategic move towards enhancing network robustness and efficiency. These nodes operate with a reduced resource footprint, ensuring a widespread and seamless network distribution. They form the bedrock of the infrastructure, interfacing directly with a series of validators. These validators are pivotal in maintaining the integrity and trustworthiness of the network, each playing an instrumental role in processing transactions and securing the network's protocol.
## Blockchain Services
Blockchain Services are instrumental in ensuring seamless interoperability and data exchange across the network.
<CardGroup>
<Card title="IBC Relayer">
The IBC Relayer stands at the forefront of inter-blockchain communication,
enabling different blockchain protocols to transfer and share information
effectively.
</Card>
<Card title="IPFS/Libp2p Routing">
IPFS/Libp2p Routing underpins the decentralized routing of information,
ensuring resilient and scalable data distribution across the network.
</Card>
</CardGroup>
## Interoperability Protocols
The overarching network architecture is designed with interoperability at its core, integrating protocols such as Matrix and Pinecone to facilitate communication and data exchange across disparate systems.
- **Matrix Protocol**: A new paradigm in secure, decentralized communication.
- **Pinecone Routing**: A novel approach to establishing network pathways, enhancing the efficiency and reliability of data transmission.
docs/reference/architecture/inter-planetary-file-system.mdx
View File
docs/reference/architecture/multi-party-computation.mdx
View File
docs/reference/architecture/passkey-web-authentication.mdx
+238
View File
@@ -0,0 +1,238 @@
---
title: "WebAuthn Integration"
description: "Comprehensive guide to Sonr's WebAuthn/FIDO2 implementation for passwordless authentication"
icon: "key"
sidebarTitle: "WebAuthn Integration"
---
<Note>
This documentation covers the WebAuthn implementation in the Sonr blockchain,
providing a secure, passwordless authentication mechanism through
W3C-compliant WebAuthn protocols.
</Note>
## Overview
Sonr's WebAuthn implementation enables gasless onboarding and secure transaction authorization without requiring users to hold tokens initially. This document provides a comprehensive guide to understanding and using our WebAuthn client.
## Architecture
<Frame>
<img
src="https://cdn.sonr.io/diagrams/passkey-jwt.png"
alt="WebAuthn Architecture Diagram"
/>
</Frame>
The WebAuthn implementation is structured across three primary layers:
1. **Client Layer** (`client/auth/webauthn.go`)
- WebAuthnClient interface
- Registration and Authentication flows
- DID integration
2. **Internal WebAuthn Package** (`internal/webauthn/`)
- COSE key parsing
- CBOR encoding/decoding
- Attestation verification
- Signature verification (ES256/RS256)
3. **DID Module Layer** (`x/did/keeper/`)
- WebAuthn controller verifier
- Credential storage in DID documents
- Challenge generation and validation
## API Reference
### WebAuthnClient Interface
<CodeGroup>
```go
type WebAuthnClient interface {
// Registration Operations
BeginRegistration(ctx context.Context, opts *RegistrationOptions) (*RegistrationChallenge, error)
CompleteRegistration(ctx context.Context, challenge *RegistrationChallenge, response *AuthenticatorAttestationResponse) (*WebAuthnCredential, error)
// Authentication Operations
BeginAuthentication(ctx context.Context, opts *AuthenticationOptions) (*AuthenticationChallenge, error)
CompleteAuthentication(ctx context.Context, challenge *AuthenticationChallenge, response *AuthenticatorAssertionResponse, credentialID string) (*AuthenticationResult, error)
// Credential Management Methods...
}
```
</CodeGroup>
## Usage Examples
### Registration Flow
<CodeGroup>
```go Registration Example
func registerWebAuthn() error {
client := auth.NewWebAuthnClient()
ctx := context.Background()
// Begin registration
regOpts := &auth.RegistrationOptions{
UserID: "user123",
Username: "alice@example.com",
DisplayName: "Alice Smith",
UserVerification: "preferred",
}
challenge, err := client.BeginRegistration(ctx, regOpts)
if err != nil {
return err
}
// Complete registration
response := &auth.AuthenticatorAttestationResponse{
ClientDataJSON: clientDataJSON,
AttestationObject: attestationObject,
}
credential, err := client.CompleteRegistration(ctx, challenge, response)
return err
}
```
</CodeGroup>
### Authentication Flow
<CodeGroup>
```go Authentication Example
func authenticateWebAuthn(credentialID string) error {
client := auth.NewWebAuthnClient()
ctx := context.Background()
// Begin authentication
authOpts := &auth.AuthenticationOptions{
UserVerification: "required",
AllowedCredentials: []*auth.CredentialDescriptor{
{
Type: "public-key",
ID: []byte(credentialID),
},
},
}
challenge, err := client.BeginAuthentication(ctx, authOpts)
if err != nil {
return err
}
// Complete authentication
response := &auth.AuthenticatorAssertionResponse{
ClientDataJSON: clientDataJSON,
AuthenticatorData: authenticatorData,
Signature: signature,
UserHandle: userHandle,
}
result, err := client.CompleteAuthentication(ctx, challenge, response, credentialID)
return err
}
```
</CodeGroup>
## Security Considerations
### Supported Algorithms
<Tabs>
<Tab title="ES256">ECDSA with P-256 curve and SHA-256</Tab>
<Tab title="RS256">RSASSA-PKCS1-v1_5 with SHA-256</Tab>
</Tabs>
### Attestation Formats
<Callout type="info">
1. **none**: No attestation (development/testing) 2. **packed**:
Self-attestation or certificate chain 3. **fido-u2f**: Legacy U2F
authenticators 4. **android-safetynet**: Android device attestation
</Callout>
### Security Features
- **Challenge uniqueness**: Each challenge is unique and time-bound
- **Origin validation**: Ensures requests come from trusted origins
- **User verification**: Requires biometric or PIN when configured
- **Counter tracking**: Detects cloned credentials
- **Credential isolation**: Each DID has separate credential namespace
## Configuration
### Chain Parameters
<CodeGroup>
```json Configuration Example
{
"webauthn": {
"rp_id": "sonr.io",
"rp_name": "Sonr Network",
"timeout": 60000,
"user_verification": "preferred",
"attestation": "none",
"allowed_origins": [
"https://sonr.io",
"https://app.sonr.io"
]
}
}
```
</CodeGroup>
## Troubleshooting
<Accordion title="Common WebAuthn Issues">
- **"Invalid attestation format"**: Ensure authenticator supports the
configured format - **"Challenge mismatch"**: Verify challenge hasn't expired
- **"Origin validation failed"**: Check allowed origins list - **"User
verification required"**: Ensure authenticator supports verification
</Accordion>
## Contributing
### Development Setup
<CodeGroup>
```bash Setup Commands
# Clone repository
git clone https://github.com/sonr-io/sonr.git
# Install dependencies
make install
# Run WebAuthn tests
make test-webauthn
```
</CodeGroup>
## References
<Card
title="WebAuthn Specifications"
icon="link"
href="https://www.w3.org/TR/webauthn/"
>
Official W3C WebAuthn Specification
</Card>
<Card
title="FIDO2 CTAP"
icon="lock"
href="https://fidoalliance.org/specs/fido-v2.0/"
>
FIDO2 Client to Authenticator Protocol
</Card>
## License
Copyright 2024 Sonr Inc. Licensed under the Apache License, Version 2.0.
```
docs/reference/architecture/user-controller-authorization-network.mdx
View File
docs/reference/architecture/wallet-abstraction.mdx
View File
docs/reference/commands/snrd.mdx
+132
View File
@@ -0,0 +1,132 @@
---
title: snrd
description: The Sonr blockchain daemon (server) command
---
# snrd
The main command for running and interacting with the Sonr blockchain node.
## Usage
```shell
snrd [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `auth` | User authentication with Passkeys |
| `comet` | CometBFT subcommands |
| `config` | Utilities for managing application configuration |
| `debug` | Tool for helping with debugging your application |
| `export` | Export state to JSON |
| `genesis` | Application's genesis-related subcommands |
| `gov` | Governance utilities |
| `help` | Help about any command |
| `index-eth-tx` | Index historical eth txs |
| `init` | Initialize private validator, p2p, genesis, and application configuration files |
| `keys` | Manage your application's keys |
| `prune` | Prune app history states by keeping the recent heights and deleting old heights |
| `query` | Querying subcommands |
| `rollback` | Rollback Cosmos SDK and CometBFT state by one height |
| `snapshots` | Manage local snapshots |
| `start` | Run the full node |
| `status` | Query remote node for status |
| `tx` | Transactions subcommands |
| `version` | Print the application binary version information |
| `wallet` | Wallet operations |
## Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction (e.g., 10aatom)
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
Adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g., 10aatom)
</ParamField>
<ParamField path="help" type="boolean">
Help for snrd
</ParamField>
<ParamField path="home" type="string" default="~/.sonr">
Directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend (os|file|test)
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="boolean">
Disable colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="boolean">
Print out full stack trace on errors
</ParamField>
## Examples
### Start a node
```shell
snrd start
```
### Query node status
```shell
snrd status
```
### Initialize a new node
```shell
snrd init my-node --chain-id sonrtest_1-1
```
### Get help for any command
```shell
snrd [command] --help
```
## See Also
- [snrd auth](./snrd_auth.mdx) - User authentication with Passkeys
- [snrd genesis](./snrd_genesis.mdx) - Genesis-related subcommands
- [snrd init](./snrd_init.mdx) - Initialize node configuration
- [snrd keys](./snrd_keys.mdx) - Manage application keys
- [snrd query](./snrd_query.mdx) - Query blockchain state
- [snrd tx](./snrd_tx.mdx) - Submit transactions
docs/reference/commands/snrd_auth.mdx
+100
View File
@@ -0,0 +1,100 @@
---
title: snrd auth
description: User authentication with Passkeys
---
# snrd auth
Manage user authentication using WebAuthn/Passkey technology for decentralized identity.
## Usage
```shell
snrd auth [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `login` | Login with WebAuthn authentication |
| `register` | Register a new identity using WebAuthn |
## Flags
<ParamField path="help" type="boolean">
Help for auth
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction (e.g., 10aatom)
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
Adjustment factor to be multiplied against the estimate returned by the tx simulation
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g., 10aatom)
</ParamField>
<ParamField path="home" type="string" default="~/.sonr">
Directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled)
</ParamField>
<ParamField path="log_no_color" type="boolean">
Disable colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
Tendermint RPC interface for this chain
</ParamField>
<ParamField path="trace" type="boolean">
Print out full stack trace on errors
</ParamField>
## Examples
### Register a new identity
```shell
snrd auth register --username alice
```
### Login with existing identity
```shell
snrd auth login --username alice
```
## See Also
- [snrd auth register](./snrd_auth_register.mdx) - Register a new identity using WebAuthn
- [snrd auth login](./snrd_auth_login.mdx) - Login with WebAuthn authentication
docs/reference/commands/snrd_auth_register.mdx
+117
View File
@@ -0,0 +1,117 @@
---
title: snrd auth register
description: Register a new decentralized identity using WebAuthn/Passkey authentication
---
# snrd auth register
Register a new decentralized identity using WebAuthn/Passkey authentication.
This command will:
1. Start a local auth server
2. Open your browser for WebAuthn credential creation
3. Create a DID document with your WebAuthn credential
4. Auto-create a DWN vault for data storage
## Usage
```shell
snrd auth register [flags]
```
## Flags
<ParamField path="username" type="string" required>
Username for the new identity
</ParamField>
<ParamField path="auto-vault" type="boolean" default="true">
Automatically create vault for DID
</ParamField>
<ParamField path="webauthn" type="boolean" default="true">
Use WebAuthn for registration
</ParamField>
<ParamField path="help" type="boolean">
Help for register
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction (e.g., 10aatom)
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
Adjustment factor to be multiplied against the estimate returned by the tx simulation
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g., 10aatom)
</ParamField>
<ParamField path="home" type="string" default="~/.sonr">
Directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level
</ParamField>
<ParamField path="log_no_color" type="boolean">
Disable colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
Tendermint RPC interface for this chain
</ParamField>
<ParamField path="trace" type="boolean">
Print out full stack trace on errors
</ParamField>
## Examples
### Basic registration
```shell
snrd auth register --username alice
```
### Registration without auto vault creation
```shell
snrd auth register --username alice --auto-vault=false
```
### Registration with custom chain ID
```shell
snrd auth register --username alice --chain-id sonrtest_1-1
```
## See Also
- [snrd auth](./snrd_auth.mdx) - User authentication with Passkeys
- [snrd auth login](./snrd_auth_login.mdx) - Login with WebAuthn authentication
docs/reference/commands/snrd_genesis.mdx
+100
View File
@@ -0,0 +1,100 @@
---
title: snrd genesis
description: Application's genesis-related subcommands
---
# snrd genesis
Application's genesis-related subcommands
## Usage
```shell
snrd genesis [flags]
```
```shell
snrd genesis [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `add-genesis-account` | Add a genesis account to genesis.json |
| `collect-gentxs` | Collect genesis txs and output a genesis.json file |
| `gentx` | Generate a genesis tx carrying a self delegation |
| `migrate` | Migrate genesis to a specified target version |
| `validate` | Validates the genesis file at the default location or at the location passed as an arg |
## Flags
<ParamField path="help" type="string">
for genesis
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd genesis
```
## See Also
- [snrd](./snrd.mdx) - Parent command
docs/reference/commands/snrd_genesis_add-genesis-account.mdx
+122
View File
@@ -0,0 +1,122 @@
---
title: snrd genesis add-genesis-account
description: Add a genesis account to genesis.json. The provided account must specify
---
# snrd genesis add-genesis-account
Add a genesis account to genesis.json. The provided account must specify
## Usage
```shell
snrd genesis add-genesis-account [address_or_key_name] [coin][,[coin]] [flags]
```
## Flags
<ParamField path="append" type="string">
the coins to an account already in the genesis.json file
</ParamField>
<ParamField path="grpc-addr" type="string">
the gRPC endpoint to use for this chain
</ParamField>
<ParamField path="grpc-insecure" type="string">
gRPC over insecure channels, if not the server must use TLS
</ParamField>
<ParamField path="height" type="integer">
Use a specific height to query state at (this can error if the node is pruning state)
</ParamField>
<ParamField path="help" type="string">
for add-genesis-account
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
The application home directory
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend (os|file|kwallet|pass|test)
</ParamField>
<ParamField path="module-name" type="string">
module account name
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to CometBFT RPC interface for this chain
</ParamField>
<ParamField path="output" type="string" default="text">
Output format (text|json)
</ParamField>
<ParamField path="vesting-amount" type="string">
amount of coins for vesting accounts
</ParamField>
<ParamField path="vesting-end-time" type="integer">
schedule end time (unix epoch) for vesting accounts
</ParamField>
<ParamField path="vesting-start-time" type="integer">
schedule start time (unix epoch) for vesting accounts
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Add account with initial coins
```shell
snrd genesis add-genesis-account alice 1000000snr
```
## See Also
- [snrd genesis](./snrd_genesis.mdx) - Parent command
docs/reference/commands/snrd_genesis_collect-gentxs.mdx
+98
View File
@@ -0,0 +1,98 @@
---
title: snrd genesis collect-gentxs
description: Collect genesis txs and output a genesis.json file
---
# snrd genesis collect-gentxs
Collect genesis txs and output a genesis.json file. This command iterates over all genesis transactions in the gentx directory and merges them into the genesis.json file.
## Usage
```shell
snrd genesis collect-gentxs [flags]
```
## Flags
<ParamField path="gentx-dir" type="string">
Override default "gentx" directory from which collect and execute genesis transactions; default [--home]/config/gentx/
</ParamField>
<ParamField path="help" type="boolean">
Help for collect-gentxs
</ParamField>
<ParamField path="home" type="string" default="~/.sonr">
The application home directory
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction (e.g., 10aatom)
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
Adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g., 10aatom)
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="boolean">
Disable colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="boolean">
Print out full stack trace on errors
</ParamField>
## Examples
### Collect genesis transactions
```shell
snrd genesis collect-gentxs
```
### Collect from custom directory
```shell
snrd genesis collect-gentxs --gentx-dir ./custom-gentx/
```
## See Also
- [snrd genesis](./snrd_genesis.mdx) - Genesis-related subcommands
- [snrd genesis gentx](./snrd_genesis_gentx.mdx) - Generate a genesis tx carrying a self delegation
- [snrd genesis add-genesis-account](./snrd_genesis_add-genesis-account.mdx) - Add a genesis account to genesis.json
docs/reference/commands/snrd_genesis_export.mdx
+100
View File
@@ -0,0 +1,100 @@
---
title: snrd genesis export
description: Application's genesis-related subcommands
---
# snrd genesis export
Application's genesis-related subcommands
## Usage
```shell
snrd genesis [flags]
```
```shell
snrd genesis [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `add-genesis-account` | Add a genesis account to genesis.json |
| `collect-gentxs` | Collect genesis txs and output a genesis.json file |
| `gentx` | Generate a genesis tx carrying a self delegation |
| `migrate` | Migrate genesis to a specified target version |
| `validate` | Validates the genesis file at the default location or at the location passed as an arg |
## Flags
<ParamField path="help" type="string">
for genesis
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd genesis export
```
## See Also
- [snrd genesis](./snrd_genesis.mdx) - Parent command
docs/reference/commands/snrd_genesis_gentx.mdx
+210
View File
@@ -0,0 +1,210 @@
---
title: snrd genesis gentx
description: Generate a genesis transaction that creates a validator with a self-delegation,
---
# snrd genesis gentx
Generate a genesis transaction that creates a validator with a self-delegation,
## Usage
```shell
snrd genesis gentx [key_name] [amount] [flags]
```
## Flags
<ParamField path="account-number" type="string">
The account number of the signing account (offline mode only)
</ParamField>
<ParamField path="amount" type="string">
Amount of coins to bond
</ParamField>
<ParamField path="aux" type="string">
aux signer data instead of sending a tx
</ParamField>
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="commission-max-change-rate" type="string">
The maximum commission change rate percentage (per day)
</ParamField>
<ParamField path="commission-max-rate" type="string">
The maximum commission rate percentage
</ParamField>
<ParamField path="commission-rate" type="string">
The initial commission rate percentage
</ParamField>
<ParamField path="details" type="string">
The validator's (optional) details
</ParamField>
<ParamField path="dry-run" type="string">
the --gas flag and perform a simulation of a transaction, but don't broadcast it (when enabled, the local Keybase is not accessible)
</ParamField>
<ParamField path="fee-granter" type="string">
Fee granter grants fees for the transaction
</ParamField>
<ParamField path="fee-payer" type="string">
Fee payer pays fees for the transaction instead of deducting from the signer
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10uatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas" type="string" default="200000">
gas limit to set per-transaction; set to "auto" to calculate sufficient gas automatically. Note: "auto" option doesn't always report accurate results. Set a valid coin value to adjust the result. Can be used instead of "fees".
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices in decimal format to determine the transaction fee (e.g. 0.1uatom)
</ParamField>
<ParamField path="generate-only" type="string">
an unsigned transaction and write it to STDOUT (when enabled, the local Keybase only accessed when providing a key name)
</ParamField>
<ParamField path="help" type="string">
for gentx
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
The application home directory
</ParamField>
<ParamField path="identity" type="string">
The (optional) identity signature (ex. UPort or Keybase)
</ParamField>
<ParamField path="ip" type="string" default="192.168.1.203">
The node's public P2P IP
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend (os|file|kwallet|pass|test|memory)
</ParamField>
<ParamField path="keyring-dir" type="string">
The client Keyring directory; if omitted, the default 'home' directory will be used
</ParamField>
<ParamField path="ledger" type="string">
a connected Ledger device
</ParamField>
<ParamField path="min-self-delegation" type="string">
The minimum self delegation required on the validator
</ParamField>
<ParamField path="moniker" type="string">
The validator's (optional) moniker
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to CometBFT rpc interface for this chain
</ParamField>
<ParamField path="node-id" type="string">
The node's NodeID
</ParamField>
<ParamField path="note" type="string">
Note to add a description to the transaction (previously --memo)
</ParamField>
<ParamField path="offline" type="string">
mode (does not allow any online functionality)
</ParamField>
<ParamField path="output-document" type="string">
Write the genesis transaction JSON document to the given file instead of the default location
</ParamField>
<ParamField path="p2p-port" type="string" default="26656">
The node's public P2P port
</ParamField>
<ParamField path="pubkey" type="string">
The validator's Protobuf JSON encoded public key
</ParamField>
<ParamField path="security-contact" type="string">
The validator's (optional) security contact email
</ParamField>
<ParamField path="sequence" type="string">
The sequence number of the signing account (offline mode only)
</ParamField>
<ParamField path="sign-mode" type="string">
Choose sign mode (direct|amino-json|direct-aux|textual), this is an advanced feature
</ParamField>
<ParamField path="timeout-height" type="string">
Set a block timeout height to prevent the tx from being committed past a certain height
</ParamField>
<ParamField path="tip" type="string">
Tip is the amount that is going to be transferred to the fee payer on the target chain. This flag is only valid when used with --aux, and is ignored if the target chain didn't enable the TipDecorator
</ParamField>
<ParamField path="website" type="string">
The validator's (optional) website
</ParamField>
<ParamField path="yes" type="string">
tx broadcasting prompt confirmation
</ParamField>
## Global Flags
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Generate genesis transaction
```shell
snrd genesis gentx alice 1000000snr --chain-id sonrtest_1-1
```
## See Also
- [snrd genesis](./snrd_genesis.mdx) - Parent command
docs/reference/commands/snrd_genesis_init.mdx
+100
View File
@@ -0,0 +1,100 @@
---
title: snrd genesis init
description: Application's genesis-related subcommands
---
# snrd genesis init
Application's genesis-related subcommands
## Usage
```shell
snrd genesis [flags]
```
```shell
snrd genesis [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `add-genesis-account` | Add a genesis account to genesis.json |
| `collect-gentxs` | Collect genesis txs and output a genesis.json file |
| `gentx` | Generate a genesis tx carrying a self delegation |
| `migrate` | Migrate genesis to a specified target version |
| `validate` | Validates the genesis file at the default location or at the location passed as an arg |
## Flags
<ParamField path="help" type="string">
for genesis
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd genesis init
```
## See Also
- [snrd genesis](./snrd_genesis.mdx) - Parent command
docs/reference/commands/snrd_genesis_migrate.mdx
+94
View File
@@ -0,0 +1,94 @@
---
title: snrd genesis migrate
description: Migrate the source genesis into the target version and print to STDOUT
---
# snrd genesis migrate
Migrate the source genesis into the target version and print to STDOUT
## Usage
```shell
snrd genesis migrate [target-version] [genesis-file] [flags]
```
## Flags
<ParamField path="chain-id" type="string">
Override chain_id with this flag
</ParamField>
<ParamField path="genesis-time" type="string">
Override genesis_time with this flag
</ParamField>
<ParamField path="help" type="string">
for migrate
</ParamField>
<ParamField path="output-document" type="string">
Exported state is written to the given file instead of STDOUT
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd genesis migrate
```
## See Also
- [snrd genesis](./snrd_genesis.mdx) - Parent command
docs/reference/commands/snrd_genesis_validate.mdx
+86
View File
@@ -0,0 +1,86 @@
---
title: snrd genesis validate
description: Validates the genesis file at the default location or at the location passed as an arg
---
# snrd genesis validate
Validates the genesis file at the default location or at the location passed as an arg
## Usage
```shell
snrd genesis validate [file] [flags]
```
## Flags
<ParamField path="help" type="string">
for validate
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd genesis validate
```
## See Also
- [snrd genesis](./snrd_genesis.mdx) - Parent command
docs/reference/commands/snrd_help.mdx
+86
View File
@@ -0,0 +1,86 @@
---
title: snrd help
description: Help provides help for any command in the application.
---
# snrd help
Help provides help for any command in the application.
## Usage
```shell
snrd help [command] [flags]
```
## Flags
<ParamField path="help" type="string">
for help
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd help
```
## See Also
- [snrd](./snrd.mdx) - Parent command
docs/reference/commands/snrd_init.mdx
+102
View File
@@ -0,0 +1,102 @@
---
title: snrd init
description: Initialize validators's and node's configuration files.
---
# snrd init
Initialize validators's and node's configuration files.
## Usage
```shell
snrd init [moniker] [flags]
```
## Flags
<ParamField path="chain-id" type="string">
genesis file chain-id, if left blank will be randomly created
</ParamField>
<ParamField path="default-denom" type="string">
genesis file default denomination, if left blank default value is 'stake'
</ParamField>
<ParamField path="help" type="string">
for init
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
node's home directory
</ParamField>
<ParamField path="initial-height" type="integer" default="1">
specify the initial block height at genesis
</ParamField>
<ParamField path="overwrite" type="string">
the genesis.json file
</ParamField>
<ParamField path="recover" type="string">
seed phrase to recover existing key instead of creating
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd init
```
## See Also
- [snrd](./snrd.mdx) - Parent command
docs/reference/commands/snrd_keys.mdx
+94
View File
@@ -0,0 +1,94 @@
---
title: snrd keys
description: Keyring management commands. These keys may be in any format supported by the
---
# snrd keys
Keyring management commands. These keys may be in any format supported by the
## Usage
```shell
snrd keys [command]
```
## Flags
<ParamField path="help" type="string">
for keys
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
The application home directory
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend (os|file|test)
</ParamField>
<ParamField path="keyring-dir" type="string">
The client Keyring directory; if omitted, the default 'home' directory will be used
</ParamField>
<ParamField path="output" type="string" default="text">
Output format (text|json)
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd keys
```
## See Also
- [snrd](./snrd.mdx) - Parent command
docs/reference/commands/snrd_keys_add.mdx
+158
View File
@@ -0,0 +1,158 @@
---
title: snrd keys add
description: Derive a new private key and encrypt to disk.
---
# snrd keys add
Derive a new private key and encrypt to disk.
## Usage
```shell
snrd keys add <name> [flags]
```
## Flags
<ParamField path="account" type="integer">
Account number for HD derivation (less than equal 2147483647)
</ParamField>
<ParamField path="coin-type" type="integer" default="60">
coin type number for HD derivation
</ParamField>
<ParamField path="dry-run" type="string">
action, but don't add key to local keystore
</ParamField>
<ParamField path="hd-path" type="string">
Manual HD Path derivation (overrides BIP44 config)
</ParamField>
<ParamField path="help" type="string">
for add
</ParamField>
<ParamField path="index" type="integer">
Address index number for HD derivation (less than equal 2147483647)
</ParamField>
<ParamField path="interactive" type="string">
prompt user for BIP39 passphrase and mnemonic
</ParamField>
<ParamField path="key-type" type="string" default="eth_secp256k1">
Key signing algorithm to generate keys for
</ParamField>
<ParamField path="ledger" type="string">
a local reference to a private key on a Ledger device
</ParamField>
<ParamField path="multisig" type="string">
List of key names stored in keyring to construct a public legacy multisig key
</ParamField>
<ParamField path="multisig-threshold" type="integer" default="1">
K out of N required signatures. For use in conjunction with --multisig
</ParamField>
<ParamField path="no-backup" type="string">
print out seed phrase (if others are watching the terminal)
</ParamField>
<ParamField path="nosort" type="string">
passed to --multisig are taken in the order they're supplied
</ParamField>
<ParamField path="pubkey" type="string">
Parse a public key in JSON format and saves key info to &lt;name&gt; file.
</ParamField>
<ParamField path="pubkey-base64" type="string">
Parse a public key in base64 format and saves key info.
</ParamField>
<ParamField path="recover" type="string">
seed phrase to recover existing key instead of creating
</ParamField>
<ParamField path="source" type="string">
Import mnemonic from a file (only usable when recover or interactive is passed)
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
The application home directory
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend (os|file|test)
</ParamField>
<ParamField path="keyring-dir" type="string">
The client Keyring directory; if omitted, the default 'home' directory will be used
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="output" type="string" default="text">
Output format (text|json)
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Add new key
```shell
snrd keys add alice
```
## See Also
- [snrd keys](./snrd_keys.mdx) - Parent command
docs/reference/commands/snrd_keys_delete.mdx
+102
View File
@@ -0,0 +1,102 @@
---
title: snrd keys delete
description: Delete keys from the Keybase backend.
---
# snrd keys delete
Delete keys from the Keybase backend.
## Usage
```shell
snrd keys delete <name>... [flags]
```
## Flags
<ParamField path="force" type="string">
the key unconditionally without asking for the passphrase. Deprecated.
</ParamField>
<ParamField path="help" type="string">
for delete
</ParamField>
<ParamField path="yes" type="string">
confirmation prompt when deleting offline or ledger key references
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
The application home directory
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend (os|file|test)
</ParamField>
<ParamField path="keyring-dir" type="string">
The client Keyring directory; if omitted, the default 'home' directory will be used
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="output" type="string" default="text">
Output format (text|json)
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd keys delete
```
## See Also
- [snrd keys](./snrd_keys.mdx) - Parent command
docs/reference/commands/snrd_keys_export.mdx
+102
View File
@@ -0,0 +1,102 @@
---
title: snrd keys export
description: Export a private key from the local keyring in ASCII-armored encrypted format.
---
# snrd keys export
Export a private key from the local keyring in ASCII-armored encrypted format.
## Usage
```shell
snrd keys export <name> [flags]
```
## Flags
<ParamField path="help" type="string">
for export
</ParamField>
<ParamField path="unarmored-hex" type="string">
unarmored hex privkey. Requires --unsafe.
</ParamField>
<ParamField path="unsafe" type="string">
unsafe operations. This flag must be switched on along with all unsafe operation-specific options.
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
The application home directory
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend (os|file|test)
</ParamField>
<ParamField path="keyring-dir" type="string">
The client Keyring directory; if omitted, the default 'home' directory will be used
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="output" type="string" default="text">
Output format (text|json)
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd keys export
```
## See Also
- [snrd keys](./snrd_keys.mdx) - Parent command
docs/reference/commands/snrd_keys_import.mdx
+94
View File
@@ -0,0 +1,94 @@
---
title: snrd keys import
description: Import a ASCII armored private key into the local keybase.
---
# snrd keys import
Import a ASCII armored private key into the local keybase.
## Usage
```shell
snrd keys import <name> <keyfile> [flags]
```
## Flags
<ParamField path="help" type="string">
for import
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
The application home directory
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend (os|file|test)
</ParamField>
<ParamField path="keyring-dir" type="string">
The client Keyring directory; if omitted, the default 'home' directory will be used
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="output" type="string" default="text">
Output format (text|json)
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd keys import
```
## See Also
- [snrd keys](./snrd_keys.mdx) - Parent command
docs/reference/commands/snrd_keys_list.mdx
+98
View File
@@ -0,0 +1,98 @@
---
title: snrd keys list
description: Return a list of all public keys stored by this key manager
---
# snrd keys list
Return a list of all public keys stored by this key manager
## Usage
```shell
snrd keys list [flags]
```
## Flags
<ParamField path="help" type="string">
for list
</ParamField>
<ParamField path="list-names" type="string">
names only
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
The application home directory
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend (os|file|test)
</ParamField>
<ParamField path="keyring-dir" type="string">
The client Keyring directory; if omitted, the default 'home' directory will be used
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="output" type="string" default="text">
Output format (text|json)
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### List all keys
```shell
snrd keys list
```
## See Also
- [snrd keys](./snrd_keys.mdx) - Parent command
docs/reference/commands/snrd_keys_migrate.mdx
+94
View File
@@ -0,0 +1,94 @@
---
title: snrd keys migrate
description: Migrate keys from Amino to Protocol Buffers records.
---
# snrd keys migrate
Migrate keys from Amino to Protocol Buffers records.
## Usage
```shell
snrd keys migrate [flags]
```
## Flags
<ParamField path="help" type="string">
for migrate
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
The application home directory
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend (os|file|test)
</ParamField>
<ParamField path="keyring-dir" type="string">
The client Keyring directory; if omitted, the default 'home' directory will be used
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="output" type="string" default="text">
Output format (text|json)
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd keys migrate
```
## See Also
- [snrd keys](./snrd_keys.mdx) - Parent command
docs/reference/commands/snrd_keys_parse.mdx
+94
View File
@@ -0,0 +1,94 @@
---
title: snrd keys parse
description: Convert and print to stdout key addresses and fingerprints from
---
# snrd keys parse
Convert and print to stdout key addresses and fingerprints from
## Usage
```shell
snrd keys parse <hex-or-bech32-address> [flags]
```
## Flags
<ParamField path="help" type="string">
for parse
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
The application home directory
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend (os|file|test)
</ParamField>
<ParamField path="keyring-dir" type="string">
The client Keyring directory; if omitted, the default 'home' directory will be used
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="output" type="string" default="text">
Output format (text|json)
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd keys parse
```
## See Also
- [snrd keys](./snrd_keys.mdx) - Parent command
docs/reference/commands/snrd_keys_show.mdx
+114
View File
@@ -0,0 +1,114 @@
---
title: snrd keys show
description: Display keys details. If multiple names or addresses are provided,
---
# snrd keys show
Display keys details. If multiple names or addresses are provided,
## Usage
```shell
snrd keys show [name_or_address [name_or_address...]] [flags]
```
## Flags
<ParamField path="address" type="string">
the address only (cannot be used with --output)
</ParamField>
<ParamField path="bech" type="string" default="acc">
The Bech32 prefix encoding for a key (acc|val|cons)
</ParamField>
<ParamField path="device" type="string">
the address in a ledger device (cannot be used with --pubkey)
</ParamField>
<ParamField path="help" type="string">
for show
</ParamField>
<ParamField path="multisig-threshold" type="integer" default="1">
K out of N required signatures
</ParamField>
<ParamField path="pubkey" type="string">
the public key only (cannot be used with --output)
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
The application home directory
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend (os|file|test)
</ParamField>
<ParamField path="keyring-dir" type="string">
The client Keyring directory; if omitted, the default 'home' directory will be used
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="output" type="string" default="text">
Output format (text|json)
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd keys show
```
## See Also
- [snrd keys](./snrd_keys.mdx) - Parent command
docs/reference/commands/snrd_migrate.mdx
+20
View File
@@ -0,0 +1,20 @@
---
title: snrd migrate
description: unknown command "migrate" for "snrd"
---
# snrd migrate
unknown command "migrate" for "snrd"
## Examples
### Basic usage
```shell
snrd migrate
```
## See Also
- [snrd](./snrd.mdx) - Parent command
docs/reference/commands/snrd_node.mdx
+20
View File
@@ -0,0 +1,20 @@
---
title: snrd node
description: unknown command "node" for "snrd"
---
# snrd node
unknown command "node" for "snrd"
## Examples
### Basic usage
```shell
snrd node
```
## See Also
- [snrd](./snrd.mdx) - Parent command
docs/reference/commands/snrd_prune.mdx
+98
View File
@@ -0,0 +1,98 @@
---
title: snrd prune
description: Prune app history states by keeping the recent heights and deleting old heights.
---
# snrd prune
Prune app history states by keeping the recent heights and deleting old heights.
## Usage
```shell
snrd prune [pruning-method] [flags]
```
## Flags
<ParamField path="app-db-backend" type="string">
The type of database for application and snapshots databases
</ParamField>
<ParamField path="help" type="string">
for prune
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
The application home directory
</ParamField>
<ParamField path="pruning-interval" type="string">
Height interval at which pruned heights are removed from disk (ignored if pruning is not 'custom'),
</ParamField>
<ParamField path="pruning-keep-recent" type="string">
Number of recent heights to keep on disk (ignored if pruning is not 'custom')
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd prune
```
## See Also
- [snrd](./snrd.mdx) - Parent command
docs/reference/commands/snrd_query.mdx
+131
View File
@@ -0,0 +1,131 @@
---
title: snrd query
description: Querying subcommands
---
# snrd query
Querying subcommands
## Usage
```shell
snrd query [flags]
```
```shell
snrd query [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `auth` | Querying commands for the auth module |
| `authz` | Querying commands for the authz module |
| `bank` | Querying commands for the bank module |
| `block-results` | Query for a committed block's results by height |
| `blocks` | Query for paginated blocks that match a set of events |
| `circuit` | Querying commands for the circuit module |
| `comet-validator-set` | Get the full CometBFT validator set at given height |
| `consensus` | Querying commands for the consensus module |
| `dex` | Querying commands for the dex module |
| `did` | Querying commands for the did module |
| `distribution` | Querying commands for the distribution module |
| `dwn` | Querying commands for the dwn module |
| `erc20` | Querying commands for the erc20 module |
| `evidence` | Querying commands for the evidence module |
| `evm` | Querying commands for the evm module |
| `feegrant` | Querying commands for the feegrant module |
| `feemarket` | Querying commands for the fee market module |
| `gov` | Querying commands for the gov module |
| `group` | Querying commands for the group module |
| `ibc` | Querying commands for the IBC module |
| `ibc-fee` | IBC relayer incentivization query subcommands |
| `ibc-transfer` | IBC fungible token transfer query subcommands |
| `ibc-wasm` | IBC wasm manager module query subcommands |
| `interchain-accounts` | IBC interchain accounts query subcommands |
| `mint` | Querying commands for the mint module |
| `nft` | Querying commands for the nft module |
| `params` | Querying commands for the params module |
| `ratelimit` | Querying commands for the ratelimit module |
| `slashing` | Querying commands for the slashing module |
| `staking` | Querying commands for the staking module |
| `svc` | Querying commands for the svc module |
| `tokenfactory` | Querying commands for the tokenfactory module |
| `tx` | Query for a transaction by hash, "addr/seq" combination or comma-separated signatures in a committed block |
| `txs` | Query for paginated transactions that match a set of events |
| `upgrade` | Querying commands for the upgrade module |
| `wait-tx` | Wait for a transaction to be included in a block |
## Flags
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="help" type="string">
for query
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic query
```shell
snrd query
```
## See Also
- [snrd](./snrd.mdx) - Parent command
docs/reference/commands/snrd_query_account.mdx
+131
View File
@@ -0,0 +1,131 @@
---
title: snrd query account
description: Querying subcommands
---
# snrd query account
Querying subcommands
## Usage
```shell
snrd query [flags]
```
```shell
snrd query [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `auth` | Querying commands for the auth module |
| `authz` | Querying commands for the authz module |
| `bank` | Querying commands for the bank module |
| `block-results` | Query for a committed block's results by height |
| `blocks` | Query for paginated blocks that match a set of events |
| `circuit` | Querying commands for the circuit module |
| `comet-validator-set` | Get the full CometBFT validator set at given height |
| `consensus` | Querying commands for the consensus module |
| `dex` | Querying commands for the dex module |
| `did` | Querying commands for the did module |
| `distribution` | Querying commands for the distribution module |
| `dwn` | Querying commands for the dwn module |
| `erc20` | Querying commands for the erc20 module |
| `evidence` | Querying commands for the evidence module |
| `evm` | Querying commands for the evm module |
| `feegrant` | Querying commands for the feegrant module |
| `feemarket` | Querying commands for the fee market module |
| `gov` | Querying commands for the gov module |
| `group` | Querying commands for the group module |
| `ibc` | Querying commands for the IBC module |
| `ibc-fee` | IBC relayer incentivization query subcommands |
| `ibc-transfer` | IBC fungible token transfer query subcommands |
| `ibc-wasm` | IBC wasm manager module query subcommands |
| `interchain-accounts` | IBC interchain accounts query subcommands |
| `mint` | Querying commands for the mint module |
| `nft` | Querying commands for the nft module |
| `params` | Querying commands for the params module |
| `ratelimit` | Querying commands for the ratelimit module |
| `slashing` | Querying commands for the slashing module |
| `staking` | Querying commands for the staking module |
| `svc` | Querying commands for the svc module |
| `tokenfactory` | Querying commands for the tokenfactory module |
| `tx` | Query for a transaction by hash, "addr/seq" combination or comma-separated signatures in a committed block |
| `txs` | Query for paginated transactions that match a set of events |
| `upgrade` | Querying commands for the upgrade module |
| `wait-tx` | Wait for a transaction to be included in a block |
## Flags
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="help" type="string">
for query
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic query
```shell
snrd query account
```
## See Also
- [snrd query](./snrd_query.mdx) - Parent command
docs/reference/commands/snrd_query_accounts.mdx
+131
View File
@@ -0,0 +1,131 @@
---
title: snrd query accounts
description: Querying subcommands
---
# snrd query accounts
Querying subcommands
## Usage
```shell
snrd query [flags]
```
```shell
snrd query [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `auth` | Querying commands for the auth module |
| `authz` | Querying commands for the authz module |
| `bank` | Querying commands for the bank module |
| `block-results` | Query for a committed block's results by height |
| `blocks` | Query for paginated blocks that match a set of events |
| `circuit` | Querying commands for the circuit module |
| `comet-validator-set` | Get the full CometBFT validator set at given height |
| `consensus` | Querying commands for the consensus module |
| `dex` | Querying commands for the dex module |
| `did` | Querying commands for the did module |
| `distribution` | Querying commands for the distribution module |
| `dwn` | Querying commands for the dwn module |
| `erc20` | Querying commands for the erc20 module |
| `evidence` | Querying commands for the evidence module |
| `evm` | Querying commands for the evm module |
| `feegrant` | Querying commands for the feegrant module |
| `feemarket` | Querying commands for the fee market module |
| `gov` | Querying commands for the gov module |
| `group` | Querying commands for the group module |
| `ibc` | Querying commands for the IBC module |
| `ibc-fee` | IBC relayer incentivization query subcommands |
| `ibc-transfer` | IBC fungible token transfer query subcommands |
| `ibc-wasm` | IBC wasm manager module query subcommands |
| `interchain-accounts` | IBC interchain accounts query subcommands |
| `mint` | Querying commands for the mint module |
| `nft` | Querying commands for the nft module |
| `params` | Querying commands for the params module |
| `ratelimit` | Querying commands for the ratelimit module |
| `slashing` | Querying commands for the slashing module |
| `staking` | Querying commands for the staking module |
| `svc` | Querying commands for the svc module |
| `tokenfactory` | Querying commands for the tokenfactory module |
| `tx` | Query for a transaction by hash, "addr/seq" combination or comma-separated signatures in a committed block |
| `txs` | Query for paginated transactions that match a set of events |
| `upgrade` | Querying commands for the upgrade module |
| `wait-tx` | Wait for a transaction to be included in a block |
## Flags
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="help" type="string">
for query
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic query
```shell
snrd query accounts
```
## See Also
- [snrd query](./snrd_query.mdx) - Parent command
docs/reference/commands/snrd_query_auth.mdx
+105
View File
@@ -0,0 +1,105 @@
---
title: snrd query auth
description: Querying commands for the auth module
---
# snrd query auth
Querying commands for the auth module
## Usage
```shell
snrd query auth [flags]
```
```shell
snrd query auth [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `account` | Query account by address |
| `account-info` | Query account info which is common to all account types. |
| `accounts` | Query all the accounts |
| `address-by-acc-num` | Query account address by account number |
| `address-bytes-to-string` | Transform an address bytes to string |
| `address-string-to-bytes` | Transform an address string to bytes |
| `bech32-prefix` | Query the chain bech32 prefix (if applicable) |
| `module-account` | Query module account info by module name |
| `module-accounts` | Query all module accounts |
| `params` | Query the current auth parameters |
## Flags
<ParamField path="help" type="string">
for auth
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic query
```shell
snrd query auth
```
## See Also
- [snrd query](./snrd_query.mdx) - Parent command
docs/reference/commands/snrd_query_bank.mdx
+107
View File
@@ -0,0 +1,107 @@
---
title: snrd query bank
description: Querying commands for the bank module
---
# snrd query bank
Querying commands for the bank module
## Usage
```shell
snrd query bank [flags]
```
```shell
snrd query bank [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `balance` | Query an account balance by address and denom |
| `balances` | Query for account balances by address |
| `denom-metadata` | Query the client metadata of a given coin denomination |
| `denom-metadata-by-query-string` | Execute the DenomMetadataByQueryString RPC method |
| `denom-owners` | Query for all account addresses that own a particular token denomination. |
| `denoms-metadata` | Query the client metadata for all registered coin denominations |
| `params` | Query the current bank parameters |
| `send-enabled` | Query for send enabled entries |
| `spendable-balance` | Query the spendable balance of a single denom for a single account. |
| `spendable-balances` | Query for account spendable balances by address |
| `total-supply` | Query the total supply of coins of the chain |
| `total-supply-of` | Query the supply of a single coin denom |
## Flags
<ParamField path="help" type="string">
for bank
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic query
```shell
snrd query bank
```
## See Also
- [snrd query](./snrd_query.mdx) - Parent command
docs/reference/commands/snrd_query_consensus.mdx
+97
View File
@@ -0,0 +1,97 @@
---
title: snrd query consensus
description: Querying commands for the consensus module
---
# snrd query consensus
Querying commands for the consensus module
## Usage
```shell
snrd query consensus [flags]
```
```shell
snrd query consensus [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `comet` | Querying commands for the cosmos.base.tendermint.v1beta1.Service service |
| `params` | Query the current consensus parameters |
## Flags
<ParamField path="help" type="string">
for consensus
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic query
```shell
snrd query consensus
```
## See Also
- [snrd query](./snrd_query.mdx) - Parent command
docs/reference/commands/snrd_query_delegation.mdx
+131
View File
@@ -0,0 +1,131 @@
---
title: snrd query delegation
description: Querying subcommands
---
# snrd query delegation
Querying subcommands
## Usage
```shell
snrd query [flags]
```
```shell
snrd query [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `auth` | Querying commands for the auth module |
| `authz` | Querying commands for the authz module |
| `bank` | Querying commands for the bank module |
| `block-results` | Query for a committed block's results by height |
| `blocks` | Query for paginated blocks that match a set of events |
| `circuit` | Querying commands for the circuit module |
| `comet-validator-set` | Get the full CometBFT validator set at given height |
| `consensus` | Querying commands for the consensus module |
| `dex` | Querying commands for the dex module |
| `did` | Querying commands for the did module |
| `distribution` | Querying commands for the distribution module |
| `dwn` | Querying commands for the dwn module |
| `erc20` | Querying commands for the erc20 module |
| `evidence` | Querying commands for the evidence module |
| `evm` | Querying commands for the evm module |
| `feegrant` | Querying commands for the feegrant module |
| `feemarket` | Querying commands for the fee market module |
| `gov` | Querying commands for the gov module |
| `group` | Querying commands for the group module |
| `ibc` | Querying commands for the IBC module |
| `ibc-fee` | IBC relayer incentivization query subcommands |
| `ibc-transfer` | IBC fungible token transfer query subcommands |
| `ibc-wasm` | IBC wasm manager module query subcommands |
| `interchain-accounts` | IBC interchain accounts query subcommands |
| `mint` | Querying commands for the mint module |
| `nft` | Querying commands for the nft module |
| `params` | Querying commands for the params module |
| `ratelimit` | Querying commands for the ratelimit module |
| `slashing` | Querying commands for the slashing module |
| `staking` | Querying commands for the staking module |
| `svc` | Querying commands for the svc module |
| `tokenfactory` | Querying commands for the tokenfactory module |
| `tx` | Query for a transaction by hash, "addr/seq" combination or comma-separated signatures in a committed block |
| `txs` | Query for paginated transactions that match a set of events |
| `upgrade` | Querying commands for the upgrade module |
| `wait-tx` | Wait for a transaction to be included in a block |
## Flags
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="help" type="string">
for query
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic query
```shell
snrd query delegation
```
## See Also
- [snrd query](./snrd_query.mdx) - Parent command
docs/reference/commands/snrd_query_did.mdx
+105
View File
@@ -0,0 +1,105 @@
---
title: snrd query did
description: Querying commands for the did module
---
# snrd query did
Querying commands for the did module
## Usage
```shell
snrd query did [flags]
```
```shell
snrd query did [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `credential` | Get a W3C verifiable credential |
| `credentials` | List all W3C verifiable credentials |
| `credentials-by-did` | Get all credentials (verifiable and WebAuthn) associated with a DID |
| `document` | Get a W3C DID document by DID |
| `documents` | List all W3C DID documents |
| `documents-by-controller` | Get W3C DID documents by controller |
| `params` | Query the current consensus parameters |
| `resolve` | Resolve a DID to its document |
| `service` | Get a service endpoint from a DID document |
| `verification-method` | Get a verification method from a DID document |
## Flags
<ParamField path="help" type="string">
for did
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic query
```shell
snrd query did
```
## See Also
- [snrd query](./snrd_query.mdx) - Parent command
docs/reference/commands/snrd_query_distribution.mdx
+105
View File
@@ -0,0 +1,105 @@
---
title: snrd query distribution
description: Querying commands for the distribution module
---
# snrd query distribution
Querying commands for the distribution module
## Usage
```shell
snrd query distribution [flags]
```
```shell
snrd query distribution [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `commission` | Query distribution validator commission |
| `community-pool` | Query the amount of coins in the community pool |
| `delegator-validators` | Execute the DelegatorValidators RPC method |
| `delegator-withdraw-address` | Execute the DelegatorWithdrawAddress RPC method |
| `params` | Query the current distribution parameters. |
| `rewards` | Query all distribution delegator rewards |
| `rewards-by-validator` | Query all distribution delegator from a particular validator |
| `slashes` | Query distribution validator slashes |
| `validator-distribution-info` | Query validator distribution info |
| `validator-outstanding-rewards` | Query distribution outstanding (un-withdrawn) rewards for a validator and all their delegations |
## Flags
<ParamField path="help" type="string">
for distribution
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic query
```shell
snrd query distribution
```
## See Also
- [snrd query](./snrd_query.mdx) - Parent command
docs/reference/commands/snrd_query_dwn.mdx
+108
View File
@@ -0,0 +1,108 @@
---
title: snrd query dwn
description: Querying commands for the dwn module
---
# snrd query dwn
Querying commands for the dwn module
## Usage
```shell
snrd query dwn [flags]
```
```shell
snrd query dwn [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `cid` | Execute the CID RPC method |
| `encrypted-record` | Execute the EncryptedRecord RPC method |
| `encryption-status` | Execute the EncryptionStatus RPC method |
| `ipfs` | Execute the IPFS RPC method |
| `params` | Query the current consensus parameters |
| `permissions` | Query DWN permissions for a target |
| `protocol` | Query a specific DWN protocol |
| `protocols` | Query DWN protocols for a target |
| `record` | Query a specific DWN record |
| `records` | Query DWN records for a target |
| `vault` | Query a specific vault |
| `vaults` | Query vaults by owner |
| `vrf-contributions` | Execute the VRFContributions RPC method |
## Flags
<ParamField path="help" type="string">
for dwn
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic query
```shell
snrd query dwn
```
## See Also
- [snrd query](./snrd_query.mdx) - Parent command
docs/reference/commands/snrd_query_feegrant.mdx
+98
View File
@@ -0,0 +1,98 @@
---
title: snrd query feegrant
description: Querying commands for the feegrant module
---
# snrd query feegrant
Querying commands for the feegrant module
## Usage
```shell
snrd query feegrant [flags]
```
```shell
snrd query feegrant [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `grant` | Query details of a single grant |
| `grants-by-grantee` | Query all grants of a grantee |
| `grants-by-granter` | Query all grants by a granter |
## Flags
<ParamField path="help" type="string">
for feegrant
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic query
```shell
snrd query feegrant
```
## See Also
- [snrd query](./snrd_query.mdx) - Parent command
docs/reference/commands/snrd_query_gov.mdx
+104
View File
@@ -0,0 +1,104 @@
---
title: snrd query gov
description: Querying commands for the gov module
---
# snrd query gov
Querying commands for the gov module
## Usage
```shell
snrd query gov [flags]
```
```shell
snrd query gov [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `constitution` | Query the current chain constitution |
| `deposit` | Query details of a deposit |
| `deposits` | Query deposits on a proposal |
| `params` | Query the parameters of the governance process |
| `proposal` | Query details of a single proposal |
| `proposals` | Query proposals with optional filters |
| `tally` | Query the tally of a proposal vote |
| `vote` | Query details of a single vote |
| `votes` | Query votes of a single proposal |
## Flags
<ParamField path="help" type="string">
for gov
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic query
```shell
snrd query gov
```
## See Also
- [snrd query](./snrd_query.mdx) - Parent command
docs/reference/commands/snrd_query_slashing.mdx
+98
View File
@@ -0,0 +1,98 @@
---
title: snrd query slashing
description: Querying commands for the slashing module
---
# snrd query slashing
Querying commands for the slashing module
## Usage
```shell
snrd query slashing [flags]
```
```shell
snrd query slashing [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `params` | Query the current slashing parameters |
| `signing-info` | Query a validator's signing information |
| `signing-infos` | Query signing information of all validators |
## Flags
<ParamField path="help" type="string">
for slashing
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic query
```shell
snrd query slashing
```
## See Also
- [snrd query](./snrd_query.mdx) - Parent command
docs/reference/commands/snrd_query_staking.mdx
+109
View File
@@ -0,0 +1,109 @@
---
title: snrd query staking
description: Querying commands for the staking module
---
# snrd query staking
Querying commands for the staking module
## Usage
```shell
snrd query staking [flags]
```
```shell
snrd query staking [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `delegation` | Query a delegation based on address and validator address |
| `delegations` | Query all delegations made by one delegator |
| `delegations-to` | Query all delegations made to one validator |
| `delegator-validator` | Query validator info for given delegator validator pair |
| `delegator-validators` | Query all validators info for given delegator address |
| `historical-info` | Query historical info at given height |
| `params` | Query the current staking parameters information |
| `pool` | Query the current staking pool values |
| `redelegation` | Query a redelegation record based on delegator and a source and destination validator address |
| `unbonding-delegation` | Query an unbonding-delegation record based on delegator and validator address |
| `unbonding-delegations` | Query all unbonding-delegations records for one delegator |
| `unbonding-delegations-from` | Query all unbonding delegatations from a validator |
| `validator` | Query a validator |
| `validators` | Query for all validators |
## Flags
<ParamField path="help" type="string">
for staking
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic query
```shell
snrd query staking
```
## See Also
- [snrd query](./snrd_query.mdx) - Parent command
docs/reference/commands/snrd_query_svc.mdx
+100
View File
@@ -0,0 +1,100 @@
---
title: snrd query svc
description: Querying commands for the svc module
---
# snrd query svc
Querying commands for the svc module
## Usage
```shell
snrd query svc [flags]
```
```shell
snrd query svc [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `domain-verification` | Query domain verification status |
| `params` | Query the current consensus parameters |
| `service` | Query service information by ID |
| `services-by-domain` | Query services bound to a specific domain |
| `services-by-owner` | Query all services owned by an address |
## Flags
<ParamField path="help" type="string">
for svc
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic query
```shell
snrd query svc
```
## See Also
- [snrd query](./snrd_query.mdx) - Parent command
docs/reference/commands/snrd_query_tendermint.mdx
+131
View File
@@ -0,0 +1,131 @@
---
title: snrd query tendermint
description: Querying subcommands
---
# snrd query tendermint
Querying subcommands
## Usage
```shell
snrd query [flags]
```
```shell
snrd query [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `auth` | Querying commands for the auth module |
| `authz` | Querying commands for the authz module |
| `bank` | Querying commands for the bank module |
| `block-results` | Query for a committed block's results by height |
| `blocks` | Query for paginated blocks that match a set of events |
| `circuit` | Querying commands for the circuit module |
| `comet-validator-set` | Get the full CometBFT validator set at given height |
| `consensus` | Querying commands for the consensus module |
| `dex` | Querying commands for the dex module |
| `did` | Querying commands for the did module |
| `distribution` | Querying commands for the distribution module |
| `dwn` | Querying commands for the dwn module |
| `erc20` | Querying commands for the erc20 module |
| `evidence` | Querying commands for the evidence module |
| `evm` | Querying commands for the evm module |
| `feegrant` | Querying commands for the feegrant module |
| `feemarket` | Querying commands for the fee market module |
| `gov` | Querying commands for the gov module |
| `group` | Querying commands for the group module |
| `ibc` | Querying commands for the IBC module |
| `ibc-fee` | IBC relayer incentivization query subcommands |
| `ibc-transfer` | IBC fungible token transfer query subcommands |
| `ibc-wasm` | IBC wasm manager module query subcommands |
| `interchain-accounts` | IBC interchain accounts query subcommands |
| `mint` | Querying commands for the mint module |
| `nft` | Querying commands for the nft module |
| `params` | Querying commands for the params module |
| `ratelimit` | Querying commands for the ratelimit module |
| `slashing` | Querying commands for the slashing module |
| `staking` | Querying commands for the staking module |
| `svc` | Querying commands for the svc module |
| `tokenfactory` | Querying commands for the tokenfactory module |
| `tx` | Query for a transaction by hash, "addr/seq" combination or comma-separated signatures in a committed block |
| `txs` | Query for paginated transactions that match a set of events |
| `upgrade` | Querying commands for the upgrade module |
| `wait-tx` | Wait for a transaction to be included in a block |
## Flags
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="help" type="string">
for query
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic query
```shell
snrd query tendermint
```
## See Also
- [snrd query](./snrd_query.mdx) - Parent command
docs/reference/commands/snrd_query_tx.mdx
+106
View File
@@ -0,0 +1,106 @@
---
title: snrd query tx
description: Query for a transaction by hash or address/sequence combination
---
# snrd query tx
Example:
## Usage
```shell
snrd query tx --type=[hash|acc_seq|signature] [hash|acc_seq|signature] [flags]
```
## Flags
<ParamField path="grpc-addr" type="string">
the gRPC endpoint to use for this chain
</ParamField>
<ParamField path="grpc-insecure" type="string">
gRPC over insecure channels, if not the server must use TLS
</ParamField>
<ParamField path="height" type="integer">
Use a specific height to query state at (this can error if the node is pruning state)
</ParamField>
<ParamField path="help" type="string">
for tx
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to CometBFT RPC interface for this chain
</ParamField>
<ParamField path="output" type="string" default="text">
Output format (text|json)
</ParamField>
<ParamField path="type" type="string" default="hash">
The type to be used when querying tx, can be one of "hash", "acc_seq", "signature"
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic query
```shell
snrd query tx
```
## See Also
- [snrd query](./snrd_query.mdx) - Parent command
docs/reference/commands/snrd_rollback.mdx
+90
View File
@@ -0,0 +1,90 @@
---
title: snrd rollback
description: A state rollback is performed to recover from an incorrect application state transition,
---
# snrd rollback
A state rollback is performed to recover from an incorrect application state transition,
## Usage
```shell
snrd rollback [flags]
```
## Flags
<ParamField path="hard" type="string">
last block as well as state
</ParamField>
<ParamField path="help" type="string">
for rollback
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
The application home directory
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd rollback
```
## See Also
- [snrd](./snrd.mdx) - Parent command
docs/reference/commands/snrd_status.mdx
+90
View File
@@ -0,0 +1,90 @@
---
title: snrd status
description: Query remote node for status
---
# snrd status
Query remote node for status
## Usage
```shell
snrd status [flags]
```
## Flags
<ParamField path="help" type="string">
for status
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
Node to connect to
</ParamField>
<ParamField path="output" type="string" default="json">
Output format (text|json)
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd status
```
## See Also
- [snrd](./snrd.mdx) - Parent command
docs/reference/commands/snrd_tendermint.mdx
+98
View File
@@ -0,0 +1,98 @@
---
title: snrd tendermint
description: CometBFT subcommands
---
# snrd tendermint
CometBFT subcommands
## Usage
```shell
snrd comet [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `bootstrap-state` | Bootstrap CometBFT state at an arbitrary block height using a light client |
| `reset-state` | Remove all the data and WAL |
| `show-address` | Shows this node's CometBFT validator consensus address |
| `show-node-id` | Show this node's ID |
| `show-validator` | Show this node's CometBFT validator info |
| `unsafe-reset-all` | (unsafe) Remove all the data and WAL, reset this node's validator to genesis state |
| `version` | Print CometBFT libraries' version |
## Flags
<ParamField path="help" type="string">
for comet
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd tendermint
```
## See Also
- [snrd](./snrd.mdx) - Parent command
docs/reference/commands/snrd_tx.mdx
+135
View File
@@ -0,0 +1,135 @@
---
title: snrd tx
description: Transactions subcommands
---
# snrd tx
Transactions subcommands
## Usage
```shell
snrd tx [flags]
```
```shell
snrd tx [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `auth` | Transactions commands for the auth module |
| `authz` | Authorization transactions subcommands |
| `bank` | Bank transaction subcommands |
| `broadcast` | Broadcast transactions generated offline |
| `circuit` | Transactions commands for the circuit module |
| `consensus` | Transactions commands for the consensus module |
| `crisis` | Transactions commands for the crisis module |
| `decode` | Decode a binary encoded transaction string |
| `dex` | dex transactions subcommands |
| `did` | Transactions commands for the did module |
| `distribution` | Distribution transactions subcommands |
| `dwn` | Transactions commands for the dwn module |
| `encode` | Encode transactions generated offline |
| `erc20` | erc20 subcommands |
| `evidence` | Evidence transaction subcommands |
| `evm` | evm subcommands |
| `feegrant` | Feegrant transactions sub-commands |
| `feemarket` | Transactions commands for the feemarket module |
| `gov` | Governance transactions subcommands |
| `group` | Group transaction subcommands |
| `ibc` | IBC transaction subcommands |
| `ibc-fee` | IBC relayer incentivization transaction subcommands |
| `ibc-transfer` | IBC fungible token transfer transaction subcommands |
| `ibc-wasm` | IBC wasm manager module transaction subcommands |
| `interchain-accounts` | IBC interchain accounts transaction subcommands |
| `mint` | Transactions commands for the mint module |
| `multi-sign` | Generate multisig signatures for transactions generated offline |
| `multisign-batch` | Assemble multisig transactions in batch from batch signatures |
| `nft` | Transactions commands for the nft module |
| `ratelimit` | Transactions commands for the ratelimit module |
| `sign` | Sign a transaction generated offline |
| `sign-batch` | Sign transaction batch files |
| `simulate` | Simulate the gas usage of a transaction |
| `slashing` | Transactions commands for the slashing module |
| `staking` | Staking transaction subcommands |
| `svc` | Transactions commands for the svc module |
| `tokenfactory` | tokenfactory transactions subcommands |
| `upgrade` | Upgrade transaction subcommands |
| `validate-signatures` | validate transactions signatures |
| `vesting` | Vesting transaction subcommands |
## Flags
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="help" type="string">
for tx
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Submit transaction
```shell
snrd tx --from alice --chain-id sonrtest_1-1
```
## See Also
- [snrd](./snrd.mdx) - Parent command
docs/reference/commands/snrd_tx_bank.mdx
+97
View File
@@ -0,0 +1,97 @@
---
title: snrd tx bank
description: Bank transaction subcommands
---
# snrd tx bank
Bank transaction subcommands
## Usage
```shell
snrd tx bank [flags]
```
```shell
snrd tx bank [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `multi-send` | Send funds from one account to two or more accounts. |
| `send` | Send funds from one account to another. |
## Flags
<ParamField path="help" type="string">
for bank
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Submit transaction
```shell
snrd tx bank --from alice --chain-id sonrtest_1-1
```
## See Also
- [snrd tx](./snrd_tx.mdx) - Parent command
docs/reference/commands/snrd_tx_consensus.mdx
+86
View File
@@ -0,0 +1,86 @@
---
title: snrd tx consensus
description: Transactions commands for the consensus module
---
# snrd tx consensus
Transactions commands for the consensus module
## Usage
```shell
snrd tx consensus [flags]
```
## Flags
<ParamField path="help" type="string">
for consensus
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Submit transaction
```shell
snrd tx consensus --from alice --chain-id sonrtest_1-1
```
## See Also
- [snrd tx](./snrd_tx.mdx) - Parent command
docs/reference/commands/snrd_tx_crisis.mdx
+96
View File
@@ -0,0 +1,96 @@
---
title: snrd tx crisis
description: Transactions commands for the crisis module
---
# snrd tx crisis
Transactions commands for the crisis module
## Usage
```shell
snrd tx crisis [flags]
```
```shell
snrd tx crisis [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `invariant-broken` | Submit proof that an invariant broken |
## Flags
<ParamField path="help" type="string">
for crisis
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Submit transaction
```shell
snrd tx crisis --from alice --chain-id sonrtest_1-1
```
## See Also
- [snrd tx](./snrd_tx.mdx) - Parent command
docs/reference/commands/snrd_tx_did.mdx
+107
View File
@@ -0,0 +1,107 @@
---
title: snrd tx did
description: Transactions commands for the did module
---
# snrd tx did
Transactions commands for the did module
## Usage
```shell
snrd tx did [flags]
```
```shell
snrd tx did [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `add-service` | Add a service endpoint to a DID document |
| `add-verification-method` | Add a verification method to a DID document |
| `create-did` | Create a new DID document |
| `deactivate-did` | Deactivate a DID document |
| `issue-credential` | Issue a W3C verifiable credential |
| `link-external-wallet` | Execute the LinkExternalWallet RPC method |
| `register-web-authn-credential` | Execute the RegisterWebAuthnCredential RPC method |
| `remove-service` | Remove a service endpoint from a DID document |
| `remove-verification-method` | Remove a verification method from a DID document |
| `revoke-credential` | Revoke a W3C verifiable credential |
| `update-did` | Update an existing DID document |
| `update-params` | Execute the UpdateParams RPC method |
## Flags
<ParamField path="help" type="string">
for did
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Submit transaction
```shell
snrd tx did --from alice --chain-id sonrtest_1-1
```
## See Also
- [snrd tx](./snrd_tx.mdx) - Parent command
docs/reference/commands/snrd_tx_distribution.mdx
+100
View File
@@ -0,0 +1,100 @@
---
title: snrd tx distribution
description: Distribution transactions subcommands
---
# snrd tx distribution
Distribution transactions subcommands
## Usage
```shell
snrd tx distribution [flags]
```
```shell
snrd tx distribution [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `fund-community-pool` | Funds the community pool with the specified amount |
| `fund-validator-rewards-pool` | Fund the validator rewards pool with the specified amount |
| `set-withdraw-addr` | change the default withdraw address for rewards associated with an address |
| `withdraw-all-rewards` | withdraw all delegations rewards for a delegator |
| `withdraw-rewards` | Withdraw rewards from a given delegation address, and optionally withdraw validator commission if the delegation address given is a validator operator |
## Flags
<ParamField path="help" type="string">
for distribution
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Submit transaction
```shell
snrd tx distribution --from alice --chain-id sonrtest_1-1
```
## See Also
- [snrd tx](./snrd_tx.mdx) - Parent command
docs/reference/commands/snrd_tx_dwn.mdx
+102
View File
@@ -0,0 +1,102 @@
---
title: snrd tx dwn
description: Transactions commands for the dwn module
---
# snrd tx dwn
Transactions commands for the dwn module
## Usage
```shell
snrd tx dwn [flags]
```
```shell
snrd tx dwn [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `permissions-grant` | Grants permissions in the DWN |
| `permissions-revoke` | Revokes permissions in the DWN |
| `protocols-configure` | Configures a protocol in the DWN |
| `records-delete` | Deletes a record from the DWN |
| `records-write` | Creates or updates a record in the DWN |
| `rotate-vault-keys` | Execute the RotateVaultKeys RPC method |
| `update-params` | Execute the UpdateParams RPC method |
## Flags
<ParamField path="help" type="string">
for dwn
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Submit transaction
```shell
snrd tx dwn --from alice --chain-id sonrtest_1-1
```
## See Also
- [snrd tx](./snrd_tx.mdx) - Parent command
docs/reference/commands/snrd_tx_feegrant.mdx
+98
View File
@@ -0,0 +1,98 @@
---
title: snrd tx feegrant
description: Grant and revoke fee allowance for a grantee by a granter
---
# snrd tx feegrant
Grant and revoke fee allowance for a grantee by a granter
## Usage
```shell
snrd tx feegrant [flags]
```
```shell
snrd tx feegrant [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `grant` | Grant Fee allowance to an address |
| `prune` | Prune expired allowances |
| `revoke` | Revoke a fee grant |
## Flags
<ParamField path="help" type="string">
for feegrant
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Submit transaction
```shell
snrd tx feegrant --from alice --chain-id sonrtest_1-1
```
## See Also
- [snrd tx](./snrd_tx.mdx) - Parent command
docs/reference/commands/snrd_tx_gov.mdx
+102
View File
@@ -0,0 +1,102 @@
---
title: snrd tx gov
description: Governance transactions subcommands
---
# snrd tx gov
Governance transactions subcommands
## Usage
```shell
snrd tx gov [flags]
```
```shell
snrd tx gov [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `cancel-proposal` | Cancel governance proposal before the voting period ends. Must be signed by the proposal creator. |
| `deposit` | Deposit tokens for an active proposal |
| `draft-proposal` | Generate a draft proposal json file. The generated proposal json contains only one message (skeleton). |
| `submit-legacy-proposal` | Submit a legacy proposal along with an initial deposit |
| `submit-proposal` | Submit a proposal along with some messages, metadata and deposit |
| `vote` | Vote for an active proposal, options: yes/no/no_with_veto/abstain |
| `weighted-vote` | Vote for an active proposal, options: yes/no/no_with_veto/abstain |
## Flags
<ParamField path="help" type="string">
for gov
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Submit transaction
```shell
snrd tx gov --from alice --chain-id sonrtest_1-1
```
## See Also
- [snrd tx](./snrd_tx.mdx) - Parent command
docs/reference/commands/snrd_tx_slashing.mdx
+96
View File
@@ -0,0 +1,96 @@
---
title: snrd tx slashing
description: Transactions commands for the slashing module
---
# snrd tx slashing
Transactions commands for the slashing module
## Usage
```shell
snrd tx slashing [flags]
```
```shell
snrd tx slashing [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `unjail` | Unjail a jailed validator |
## Flags
<ParamField path="help" type="string">
for slashing
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Submit transaction
```shell
snrd tx slashing --from alice --chain-id sonrtest_1-1
```
## See Also
- [snrd tx](./snrd_tx.mdx) - Parent command
docs/reference/commands/snrd_tx_staking.mdx
+101
View File
@@ -0,0 +1,101 @@
---
title: snrd tx staking
description: Staking transaction subcommands
---
# snrd tx staking
Staking transaction subcommands
## Usage
```shell
snrd tx staking [flags]
```
```shell
snrd tx staking [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `cancel-unbond` | Cancel unbonding delegation and delegate back to the validator |
| `create-validator` | create new validator initialized with a self-delegation to it |
| `delegate` | Delegate liquid tokens to a validator |
| `edit-validator` | edit an existing validator account |
| `redelegate` | Redelegate illiquid tokens from one validator to another |
| `unbond` | Unbond shares from a validator |
## Flags
<ParamField path="help" type="string">
for staking
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Submit transaction
```shell
snrd tx staking --from alice --chain-id sonrtest_1-1
```
## See Also
- [snrd tx](./snrd_tx.mdx) - Parent command
docs/reference/commands/snrd_tx_svc.mdx
+99
View File
@@ -0,0 +1,99 @@
---
title: snrd tx svc
description: Transactions commands for the svc module
---
# snrd tx svc
Transactions commands for the svc module
## Usage
```shell
snrd tx svc [flags]
```
```shell
snrd tx svc [command]
```
## Available Commands
| Command | Description |
|---------|-------------|
| `initiate-domain-verification` | Initiate domain verification by generating a DNS TXT record token |
| `register-service` | Register a new service with the specified domain and permissions |
| `update-params` | Execute the UpdateParams RPC method |
| `verify-domain` | Verify domain ownership by checking DNS TXT records |
## Flags
<ParamField path="help" type="string">
for svc
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
The network chain ID
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Submit transaction
```shell
snrd tx svc --from alice --chain-id sonrtest_1-1
```
## See Also
- [snrd tx](./snrd_tx.mdx) - Parent command
docs/reference/commands/snrd_version.mdx
+94
View File
@@ -0,0 +1,94 @@
---
title: snrd version
description: Print the application binary version information
---
# snrd version
Print the application binary version information
## Usage
```shell
snrd version [flags]
```
## Flags
<ParamField path="help" type="string">
for version
</ParamField>
<ParamField path="long" type="string">
long version information
</ParamField>
<ParamField path="output" type="string" default="text">
Output format (text|json)
</ParamField>
## Global Flags
<ParamField path="broadcast-mode" type="string" default="sync">
Transaction broadcasting mode (sync|async)
</ParamField>
<ParamField path="chain-id" type="string">
Specify Chain ID for sending Tx
</ParamField>
<ParamField path="fees" type="string">
Fees to pay along with transaction; eg: 10aatom
</ParamField>
<ParamField path="from" type="string">
Name or address of private key with which to sign
</ParamField>
<ParamField path="gas-adjustment" type="float" default="1">
adjustment factor to be multiplied against the estimate returned by the tx simulation; if the gas limit is set manually this flag is ignored
</ParamField>
<ParamField path="gas-prices" type="string">
Gas prices to determine the transaction fee (e.g. 10aatom)
</ParamField>
<ParamField path="home" type="string" default="/Users/prad/.sonr">
directory for config and data
</ParamField>
<ParamField path="keyring-backend" type="string" default="os">
Select keyring's backend
</ParamField>
<ParamField path="log_format" type="string" default="plain">
The logging format (json|plain)
</ParamField>
<ParamField path="log_level" type="string" default="info">
The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:&lt;level&gt;,&lt;key&gt;:&lt;level&gt;')
</ParamField>
<ParamField path="log_no_color" type="string">
colored logs
</ParamField>
<ParamField path="node" type="string" default="tcp://localhost:26657">
&lt;host&gt;:&lt;port&gt; to tendermint rpc interface for this chain
</ParamField>
<ParamField path="trace" type="string">
out full stack trace on errors
</ParamField>
## Examples
### Basic usage
```shell
snrd version
```
## See Also
- [snrd](./snrd.mdx) - Parent command

Some files were not shown because too many files have changed in this diff Show More