docs(docs): add documentation site with Blume config and initial MDX pages

blume.config.ts

@@ -0,0 +1,217 @@
+import { defineConfig } from "blume";
+
+// GitHub Pages exposes no deploy URL to the build, so the workflow forwards the
+// `actions/configure-pages` outputs through these variables:
+//   BLUME_SITE = the bare origin  (e.g. https://sonr-io.github.io)
+//   BLUME_BASE = the subpath      (e.g. /sonr, or "/" on a custom domain)
+// Both are unset locally, where Blume falls back to the dev-server origin.
+const site = process.env.BLUME_SITE?.replace(/\/+$/, "") || undefined;
+const rawBase = process.env.BLUME_BASE?.replace(/\/+$/, "") ?? "";
+// A base of "" or "/" means the site is served at the root — omit the field
+// entirely rather than mounting everything under an empty segment.
+const base = rawBase && rawBase !== "/" ? rawBase : undefined;
+
+export default defineConfig({
+  title: "Sonr",
+  description:
+    "Developer documentation for the Sonr blockchain — decentralized identity, MPC-backed vaults, UCAN authorization, and the snrd node.",
+
+  // Monochrome wordmark: `currentColor` fills adapt to light/dark, and `text: ""`
+  // keeps the brand name from rendering twice beside the mark.
+  logo: { image: { light: "/logo.svg", alt: "Sonr" }, text: "" },
+
+  theme: {
+    accent: "#17c2FF",
+    action: "#279cff",
+    mode: "system",
+  },
+
+  github: { owner: "sonr-io", repo: "sonr" },
+
+  navigation: {
+    // The two bulky sections get their own header tabs. A tab scopes the
+    // sidebar to its own folder by URL prefix, keeping Reference's ~120 pages
+    // and the 77 release notes out of the main tree.
+    tabs: [
+      { label: "Reference", path: "/reference", icon: "code" },
+      // /changelog is a generated timeline, not a content page, so a bare tab
+      // path resolves to the newest entry. `href` lands on the index instead.
+      { label: "Changelog", path: "/changelog", href: "/changelog", icon: "hourglass" },
+    ],
+    // Collapsible groups, so the main sidebar reads as categories rather than
+    // one undifferentiated list.
+    sidebar: { display: "group" },
+    featured: [{ label: "sonr.io", href: "https://sonr.io", icon: "globe" }],
+  },
+
+  analytics: {
+    scripts: [
+      {
+        src: "https://www.googletagmanager.com/gtag/js?id=G-FY0WZBSGH8",
+        strategy: "async",
+      },
+      {
+        content: [
+          "window.dataLayer = window.dataLayer || [];",
+          "function gtag(){dataLayer.push(arguments);}",
+          'gtag("js", new Date());',
+          'gtag("config", "G-FY0WZBSGH8");',
+        ].join("\n"),
+      },
+    ],
+  },
+
+  // The guide categories were flattened out of /guides/* onto the site root,
+  // and the Cryptography section was dropped in favour of the sonr-io/crypto
+  // docs site. Keep the old URLs resolving.
+  redirects: [
+    {
+      "from": "/guides/development",
+      "to": "/development"
+    },
+    {
+      "from": "/guides/configure-local-node",
+      "to": "/configure-local-node"
+    },
+    {
+      "from": "/guides/register-records",
+      "to": "/register-records"
+    },
+    {
+      "from": "/guides/authorize-clients",
+      "to": "/authorize-clients"
+    },
+    {
+      "from": "/guides/broadcast-transactions",
+      "to": "/broadcast-transactions"
+    },
+    {
+      "from": "/guides/issue-payments",
+      "to": "/issue-payments"
+    },
+    {
+      "from": "/guides/onboarding",
+      "to": "/onboarding"
+    },
+    {
+      "from": "/guides/deployment",
+      "to": "/deployment"
+    },
+    {
+      "from": "/guides/vrf-key-management",
+      "to": "/vrf-key-management"
+    },
+    {
+      "from": "/guides/vrf-migration",
+      "to": "/vrf-migration"
+    },
+    {
+      "from": "/guides/architecture/delegated-proof-of-stake",
+      "to": "/architecture/delegated-proof-of-stake"
+    },
+    {
+      "from": "/guides/architecture/inter-blockchain-communication",
+      "to": "/architecture/inter-blockchain-communication"
+    },
+    {
+      "from": "/guides/architecture/passkey-web-authentication",
+      "to": "/architecture/passkey-web-authentication"
+    },
+    {
+      "from": "/guides/economics/distribution",
+      "to": "/economics/distribution"
+    },
+    {
+      "from": "/guides/economics/governance",
+      "to": "/economics/governance"
+    },
+    {
+      "from": "/guides/economics/rewards",
+      "to": "/economics/rewards"
+    },
+    {
+      "from": "/guides/economics/staking",
+      "to": "/economics/staking"
+    },
+    {
+      "from": "/guides/economics/utility",
+      "to": "/economics/utility"
+    },
+    {
+      "from": "/guides/economics/values",
+      "to": "/economics/values"
+    },
+    {
+      "from": "/guides/security/audit-report",
+      "to": "/security/audit-report"
+    },
+    {
+      "from": "/guides/security/compliance",
+      "to": "/security/compliance"
+    },
+    {
+      "from": "/guides/security/cryptography",
+      "to": "/security/cryptography"
+    },
+    {
+      "from": "/guides/security/vulnerabilities",
+      "to": "/security/vulnerabilities"
+    },
+    {
+      "from": "/guides",
+      "to": "/development"
+    },
+    {
+      "from": "/cryptography",
+      "to": "/security/cryptography"
+    },
+    {
+      "from": "/cryptography/primitives",
+      "to": "/security/cryptography"
+    },
+    {
+      "from": "/cryptography/keys-and-identifiers",
+      "to": "/security/cryptography"
+    },
+    {
+      "from": "/cryptography/mpc-enclave",
+      "to": "/security/cryptography"
+    },
+    {
+      "from": "/cryptography/ucan",
+      "to": "/security/cryptography"
+    },
+    {
+      "from": "/cryptography/webauthn",
+      "to": "/security/cryptography"
+    },
+    {
+      "from": "/cryptography/did-documents",
+      "to": "/security/cryptography"
+    },
+    {
+      "from": "/cryptography/vault-encryption",
+      "to": "/security/cryptography"
+    },
+    {
+      "from": "/cryptography/vrf",
+      "to": "/security/cryptography"
+    },
+    {
+      "from": "/cryptography/transaction-authorization",
+      "to": "/security/cryptography"
+    },
+    {
+      "from": "/cryptography/plugin-integrity",
+      "to": "/security/cryptography"
+    },
+    {
+      "from": "/cryptography/implementation-status",
+      "to": "/security/cryptography"
+    }
+  ],
+
+  lastModified: true,
+
+  ...(site ? { deployment: { site, ...(base ? { base } : {}) } } : {}),
+});

docs/(build-apps)/authorize-clients.mdx

@@ -0,0 +1,220 @@
+---
+title: "Authorization with UCAN"
+description: "Comprehensive guide to creating, validating, and managing User-Controlled Authorization Network (UCAN) tokens"
+icon: "badge-check"
+sidebar:
+  label: Client Authorization
+---
+
+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](/reference/modules/did)
+- [DWN Architecture](/reference/modules/dwn)
+- [Service Registry](/reference/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/(build-apps)/broadcast-transactions.mdx

@@ -0,0 +1,412 @@
+---
+title: Transactions
+description: Transaction types, fee structures, and token mechanics for SNR within the Sonr network
+icon: "send"
+sidebar:
+  label: Broadcast Transactions
+---
+
+## 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.
+:::
+
+## 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.
+:::
+
+### 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:
+
+:::success
+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.
+:::
+
+### 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/(build-apps)/issue-payments.mdx

@@ -0,0 +1,160 @@
+---
+title: Sending Payments
+description: A guide for sending payments and transactions on the Sonr blockchain network
+icon: "credit-card"
+sidebar:
+  label: "Issue Payments"
+---
+
+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="/reference/modules/svc">
+    Automate recurring payments and subscriptions with UCANs.
+  </Card>
+  <Card title="Cross-Chain Transfers" href="/reference/concepts/sonrnetwork">
+    Send assets to other blockchains seamlessly through IBC.
+  </Card>
+  <Card title="Token Economics" href="/reference/concepts/sonrtoken/">
+    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](/reference/modules/svc)
+- [Learn about blockchain modules](/reference/concepts/sonr)
+- [See the API Reference](/reference/)
+

docs/(build-apps)/meta.ts

@@ -0,0 +1,13 @@
+import { defineMeta } from "blume";
+
+export default defineMeta({
+  "title": "Build Apps",
+  "icon": "hammer",
+  "collapsed": false,
+  "pages": [
+    "register-records",
+    "authorize-clients",
+    "broadcast-transactions",
+    "issue-payments"
+  ]
+});

docs/(build-apps)/register-records.mdx

@@ -0,0 +1,8 @@
+---
+title: "Registering a Domain"
+description: "Comprehensive guide to creating, validating, and managing User-Controlled Authorization Network (UCAN) tokens"
+icon: "key"
+sidebar:
+  label: "Register Records"
+---
+

docs/(get-started)/configure-local-node.mdx

@@ -0,0 +1,49 @@
+---
+title: "Configuring a Validator Node"
+description: "Setup a validator node on the Sonar Network in your local environment"
+icon: "terminal"
+sidebar:
+  label: "Command Line"
+---
+
+**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/(get-started)/development.mdx

@@ -0,0 +1,8 @@
+---
+title: Local Development Setup
+description: Complete guide for becoming a Sonr blockchain validator - from setup to operations
+icon: "code"
+sidebar:
+  label: Setup Your Environment
+---
+

docs/(get-started)/meta.ts

@@ -0,0 +1,11 @@
+import { defineMeta } from "blume";
+
+export default defineMeta({
+  "title": "Get Started",
+  "icon": "rocket",
+  "collapsed": false,
+  "pages": [
+    "development",
+    "configure-local-node"
+  ]
+});

docs/(run-a-node)/deployment.mdx

@@ -0,0 +1,8 @@
+---
+title: Production Network Deployment
+description: Complete guide for becoming a Sonr blockchain validator - from setup to operations
+icon: "ship"
+sidebar:
+  label: Deploy Network & Services
+---
+

docs/(run-a-node)/meta.ts

@@ -0,0 +1,13 @@
+import { defineMeta } from "blume";
+
+export default defineMeta({
+  "title": "Run a Node",
+  "icon": "server",
+  "collapsed": false,
+  "pages": [
+    "onboarding",
+    "deployment",
+    "vrf-key-management",
+    "vrf-migration"
+  ]
+});

docs/(run-a-node)/onboarding.mdx

@@ -0,0 +1,280 @@
+---
+title: Validator Node Onboarding
+description: Complete guide for becoming a Sonr blockchain validator from setup to operations
+icon: "boxes"
+sidebar:
+  label: 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.
+:::
+
+## 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
+Begin with testnet operations to gain experience without operational risk.
+:::
+
+- 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="/development/validators/testnet">
+    Start with testnet participation to gain operational experience
+  </Card>
+  <Card title="Hardware Setup" href="/development/validators/setup">
+    Detailed hardware and infrastructure deployment guide
+  </Card>
+  <Card title="Security Guide" href="/development/validators/security">
+    Comprehensive security implementation and best practices
+  </Card>
+  <Card title="Monitoring" href="/development/validators/monitoring">
+    Setup monitoring and alerting systems for your validator
+  </Card>
+
+:::note
+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.
+:::

docs/(run-a-node)/vrf-key-management.mdx

@@ -0,0 +1,296 @@
+---
+title: VRF Key Management
+description: Guide to managing VRF keys for multi-validator encryption
+icon: "key-round"
+sidebar:
+  label: "VRF Keys"
+---
+
+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](/configure-local-node) - Node setup guide
+- [Development](/development) - Development environment setup
+- [Deployment](/deployment) - Production deployment guide

docs/(run-a-node)/vrf-migration.mdx

@@ -0,0 +1,563 @@
+---
+title: VRF Key Migration Guide
+description: Migrate existing validator nodes to use VRF keys without downtime
+icon: "arrow-right-left"
+sidebar:
+  label: "VRF Migration"
+---
+
+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**: `/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/architecture/delegated-proof-of-stake.mdx

@@ -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/architecture/inter-blockchain-communication.mdx

@@ -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/architecture/meta.ts

@@ -0,0 +1,12 @@
+import { defineMeta } from "blume";
+
+export default defineMeta({
+  "title": "Architecture",
+  "icon": "combine",
+  "collapsed": true,
+  "pages": [
+    "delegated-proof-of-stake",
+    "inter-blockchain-communication",
+    "passkey-web-authentication"
+  ]
+});

docs/architecture/passkey-web-authentication.mdx

@@ -0,0 +1,237 @@
+---
+title: "WebAuthn Integration"
+description: "Comprehensive guide to Sonr's WebAuthn/FIDO2 implementation for passwordless authentication"
+icon: "key"
+sidebar:
+  label: "WebAuthn Integration"
+---
+
+:::note
+This documentation covers the WebAuthn implementation in the Sonr blockchain,
+providing a secure, passwordless authentication mechanism through
+W3C-compliant WebAuthn protocols.
+:::
+
+## 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 inline>
+  <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
+
+:::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
+:::
+
+### 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/changelog/meta.ts

@@ -0,0 +1,7 @@
+import { defineMeta } from "blume";
+
+export default defineMeta({
+  "title": "Releases",
+  "icon": "tag",
+  "collapsed": true
+});

docs/changelog/v0-0-1.mdx

@@ -0,0 +1,20 @@
+---
+title: v0.0.1
+description: "Initial release with core blockchain features"
+type: changelog
+date: 2025-06-22T23:59:00Z
+changelog:
+  version: "0.0.1"
+  category: "Initial"
+search:
+  tags:
+    - "Core"
+---
+
+- 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

docs/changelog/v0-0-23.mdx

@@ -0,0 +1,19 @@
+---
+title: v0.0.23
+description: "Major infrastructure and documentation improvements (#38, #37, #36)"
+type: changelog
+date: 2025-06-26T23:59:00Z
+changelog:
+  version: "0.0.23"
+  category: "IPFS"
+search:
+  tags:
+    - "CI/CD"
+    - "Documentation"
+---
+
+- IPFS private network support
+- Enhanced CI/CD workflows
+- Comprehensive tokenomics documentation
+- Client integration guide
+- Research section with whitepapers

docs/changelog/v0-1-0.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.1.0
+description: "Implement Highway Service API Handlers"
+type: changelog
+date: 2025-06-28T23:58:00Z
+changelog:
+  version: "0.1.0"
+  category: "Highway"
+search:
+  tags:
+    - "API"
+---
+
+Implement Highway Service API Handlers (#39)
+
+- Highway service implementation
+- API handler creation
+- Core service functionality

docs/changelog/v0-10-0.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.0
+description: "Implement secure key management with WASM enclaves"
+type: changelog
+date: 2025-07-21T23:59:00Z
+changelog:
+  version: "0.10.0"
+  category: "Security"
+search:
+  tags:
+    - "WASM"
+---
+
+Implement secure key management with WASM enclaves (#126)
+
+- WASM-based secure enclaves
+- Hardware-level key protection
+- Enhanced cryptographic isolation

docs/changelog/v0-10-1.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.1
+description: "Major infrastructure and wallet improvements (#134, #131, #128, #127)"
+type: changelog
+date: 2025-07-31T23:57:00Z
+changelog:
+  version: "0.10.1"
+  category: "CI/CD"
+search:
+  tags:
+    - "Wallet"
+    - "EVM"
+---
+
+- 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

docs/changelog/v0-10-12.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.12
+description: "Monorepo restructure with internal packages and enhanced CI/CD"
+type: changelog
+date: 2025-08-03T23:59:00Z
+changelog:
+  version: "0.10.12"
+  category: "Monorepo"
+search:
+  tags:
+    - "CI/CD"
+---
+
+Monorepo restructure with internal packages and enhanced CI/CD (#151)
+
+- Internal package architecture
+- CI/CD pipeline improvements
+- Better code organization

docs/changelog/v0-10-13.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.13
+description: "Refactor x/dwn vaults and introduce gasless transactions"
+type: changelog
+date: 2025-08-05T23:57:00Z
+changelog:
+  version: "0.10.13"
+  category: "DWN"
+search:
+  tags:
+    - "Gasless"
+---
+
+Refactor x/dwn vaults and introduce gasless transactions (#154)
+
+- Vault system refactoring
+- Gasless transaction support
+- Enhanced user experience

docs/changelog/v0-10-14.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.14
+description: "Complete Highway proxy server implementation with asynq and proto.Actor"
+type: changelog
+date: 2025-08-05T23:58:00Z
+changelog:
+  version: "0.10.14"
+  category: "Highway"
+search:
+  tags:
+    - "Asynq"
+---
+
+Complete Highway proxy server implementation with asynq and proto.Actor (#157)
+
+- Asynq task queue integration
+- Actor-based concurrency model
+- Improved task processing

docs/changelog/v0-10-15.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.15
+description: "Migrate Highway service to Echo framework with WebSocket/SSE and JWT auth"
+type: changelog
+date: 2025-08-05T23:59:00Z
+changelog:
+  version: "0.10.15"
+  category: "Highway"
+search:
+  tags:
+    - "WebSocket"
+---
+
+Migrate Highway service to Echo framework with WebSocket/SSE and JWT auth (#159)
+
+- Echo framework migration
+- Real-time WebSocket support
+- JWT authentication system

docs/changelog/v0-10-16.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.16
+description: "Implement auto-create DWN vault with comprehensive security improvements"
+type: changelog
+date: 2025-08-06T23:58:00Z
+changelog:
+  version: "0.10.16"
+  category: "DWN"
+search:
+  tags:
+    - "Security"
+---
+
+Implement auto-create DWN vault with comprehensive security improvements (#161)
+
+- Automatic vault provisioning
+- Enhanced security measures
+- Improved user onboarding

docs/changelog/v0-10-17.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.17
+description: "Implement WebAuthn CLI registration with gasless transactions"
+type: changelog
+date: 2025-08-06T23:59:00Z
+changelog:
+  version: "0.10.17"
+  category: "WebAuthn"
+search:
+  tags:
+    - "CLI"
+---
+
+Implement WebAuthn CLI registration with gasless transactions (#168)
+
+- CLI-based WebAuthn registration
+- Browser integration for credential creation
+- Gasless onboarding flow

docs/changelog/v0-10-19.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.19
+description: "Migrate documentation to Mintlify structure (#172) and migrate x/ucan module to internal library"
+type: changelog
+date: 2025-08-08T23:58:00Z
+changelog:
+  version: "0.10.19"
+  category: "Documentation"
+search:
+  tags:
+    - "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

docs/changelog/v0-10-2.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.2
+description: "Streamline starship configuration and local development"
+type: changelog
+date: 2025-07-31T23:58:00Z
+changelog:
+  version: "0.10.2"
+  category: "Starship"
+search:
+  tags:
+    - "Development"
+---
+
+Streamline starship configuration and local development (#135)
+
+- Simplified Starship setup
+- Enhanced local development workflow
+- Better developer experience

docs/changelog/v0-10-20.mdx

@@ -0,0 +1,19 @@
+---
+title: v0.10.20
+description: "Refactor Motor WASM plugin as MPC-based UCAN source"
+type: changelog
+date: 2025-08-08T23:59:00Z
+changelog:
+  version: "0.10.20"
+  category: "Motor"
+search:
+  tags:
+    - "WASM"
+    - "MPC"
+---
+
+Refactor Motor WASM plugin as MPC-based UCAN source (#177)
+
+- Multi-party computation integration
+- WASM-based secure execution
+- UCAN capability management

docs/changelog/v0-10-22.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.22
+description: "Move interchain tests to dedicated location"
+type: changelog
+date: 2025-08-09T23:57:00Z
+changelog:
+  version: "0.10.22"
+  category: "Testing"
+search:
+  tags:
+    - "Refactor"
+---
+
+Move interchain tests to dedicated location (#178)
+
+- Improved test organization
+- Separated integration tests
+- Better test maintainability

docs/changelog/v0-10-23.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.23
+description: "Enhance init command with VRF keypair generation and SonrContext system"
+type: changelog
+date: 2025-08-09T23:58:00Z
+changelog:
+  version: "0.10.23"
+  category: "VRF"
+search:
+  tags:
+    - "Context"
+---
+
+Enhance init command with VRF keypair generation and SonrContext system (#180)
+
+- Verifiable Random Function integration
+- SonrContext for session management
+- Enhanced initialization process

docs/changelog/v0-10-24.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.24
+description: "Implement consensus-based encryption for DWN module"
+type: changelog
+date: 2025-08-09T23:59:00Z
+changelog:
+  version: "0.10.24"
+  category: "DWN"
+search:
+  tags:
+    - "Encryption"
+---
+
+Implement consensus-based encryption for DWN module (#181)
+
+- Validator-based encryption keys
+- Consensus-driven key management
+- Enhanced data privacy

docs/changelog/v0-10-25.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.25
+description: "Implement gasless WebAuthn registration with comprehensive security audit"
+type: changelog
+date: 2025-08-11T23:59:00Z
+changelog:
+  version: "0.10.25"
+  category: "WebAuthn"
+search:
+  tags:
+    - "Security"
+---
+
+Implement gasless WebAuthn registration with comprehensive security audit (#182)
+
+- Security-audited gasless registration flow
+- Anti-abuse mechanisms
+- Credential uniqueness enforcement

docs/changelog/v0-10-27.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.27
+description: "Implement WebAuthn gasless transactions with comprehensive protocol integration"
+type: changelog
+date: 2025-08-12T23:59:00Z
+changelog:
+  version: "0.10.27"
+  category: "WebAuthn"
+search:
+  tags:
+    - "Gasless"
+---
+
+Implement WebAuthn gasless transactions with comprehensive protocol integration (#186)
+
+- Gasless onboarding for new users
+- WebAuthn-based transaction signing
+- Eliminated token requirement for registration

docs/changelog/v0-10-28.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.28
+description: "Implement monorepo structure with pnpm workspaces and changesets"
+type: changelog
+date: 2025-08-13T23:58:00Z
+changelog:
+  version: "0.10.28"
+  category: "Monorepo"
+search:
+  tags:
+    - "pnpm"
+---
+
+Implement monorepo structure with pnpm workspaces and changesets (#189)
+
+- Modern monorepo architecture
+- pnpm workspace management
+- Automated versioning with changesets

docs/changelog/v0-10-3.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.3
+description: "Streamline Docker build for enhanced efficiency"
+type: changelog
+date: 2025-07-31T23:59:00Z
+changelog:
+  version: "0.10.3"
+  category: "Docker"
+search:
+  tags:
+    - "Build"
+---
+
+Streamline Docker build for enhanced efficiency (#136)
+
+- Optimized Docker build process
+- Reduced image sizes
+- Faster build times

docs/changelog/v0-10-31.mdx

@@ -0,0 +1,16 @@
+---
+title: v0.10.31
+description: "Enable Docker-based testnet execution"
+type: changelog
+date: 2025-08-13T23:59:00Z
+changelog:
+  version: "0.10.31"
+  category: "Docker"
+search:
+  tags:
+    - "Testnet"
+---
+
+- Simplified testnet deployment via Docker
+- Containerized node operation
+- Quick local testing environment

docs/changelog/v0-10-32.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.32
+description: "Implement Go client SDK with transaction signing and broadcasting"
+type: changelog
+date: 2025-08-14T23:58:00Z
+changelog:
+  version: "0.10.32"
+  category: "SDK"
+search:
+  tags:
+    - "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

docs/changelog/v0-10-33.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.33
+description: "Implement UCAN permission validation for wallet transactions"
+type: changelog
+date: 2025-08-14T23:59:00Z
+changelog:
+  version: "0.10.33"
+  category: "UCAN"
+search:
+  tags:
+    - "Wallet"
+---
+
+Implement UCAN permission validation for wallet transactions (#197)
+
+- User-Controlled Authorization Networks integration
+- Permission-based transaction validation
+- Enhanced wallet security model

docs/changelog/v0-10-34.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.34
+description: "Implement CLI commands for wallet module"
+type: changelog
+date: 2025-08-15T23:57:00Z
+changelog:
+  version: "0.10.34"
+  category: "CLI"
+search:
+  tags:
+    - "Wallet"
+---
+
+Implement CLI commands for wallet module (#198)
+
+- Comprehensive wallet management via CLI
+- Transaction signing and broadcasting commands
+- Key management operations

docs/changelog/v0-10-6.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.6
+description: "Introduce Starship network configurations for devnet and testnet"
+type: changelog
+date: 2025-08-01T23:58:00Z
+changelog:
+  version: "0.10.6"
+  category: "Starship"
+search:
+  tags:
+    - "Network"
+---
+
+Introduce Starship network configurations for devnet and testnet (#139)
+
+- Starship integration for local development
+- Multi-network configuration support
+- Simplified network management

docs/changelog/v0-10-8.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.8
+description: "Optimize deployment workflows and update infrastructure configuration"
+type: changelog
+date: 2025-08-01T23:59:00Z
+changelog:
+  version: "0.10.8"
+  category: "Deployment"
+search:
+  tags:
+    - "Infrastructure"
+---
+
+Optimize deployment workflows and update infrastructure configuration (#141)
+
+- Streamlined deployment process
+- Infrastructure updates
+- Performance optimizations

docs/changelog/v0-10-9.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.10.9
+description: "Enhance testnet configuration with faucet and explorer settings"
+type: changelog
+date: 2025-08-02T23:59:00Z
+changelog:
+  version: "0.10.9"
+  category: "Testnet"
+search:
+  tags:
+    - "Infrastructure"
+---
+
+Enhance testnet configuration with faucet and explorer settings (#145)
+
+- Testnet faucet integration
+- Block explorer configuration
+- Improved developer experience

docs/changelog/v0-11-0.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.11.0
+description: "Implement comprehensive cryptographic security enhancements"
+type: changelog
+date: 2025-08-15T23:58:00Z
+changelog:
+  version: "0.11.0"
+  category: "Cryptography"
+search:
+  tags:
+    - "Security"
+---
+
+Implement comprehensive cryptographic security enhancements (#200)
+
+- Major cryptographic subsystem overhaul
+- Enhanced encryption algorithms
+- Improved key management system

docs/changelog/v0-11-1.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.11.1
+description: "Improve secure memory handling for enhanced security"
+type: changelog
+date: 2025-08-15T23:59:00Z
+changelog:
+  version: "0.11.1"
+  category: "Security"
+search:
+  tags:
+    - "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

docs/changelog/v0-11-2.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.11.2
+description: "Transform UI package to shadcn monorepo architecture for uniform styling"
+type: changelog
+date: 2025-08-16T23:59:00Z
+changelog:
+  version: "0.11.2"
+  category: "UI"
+search:
+  tags:
+    - "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

docs/changelog/v0-11-3.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.11.3
+description: "Complete DID keeper implementation with W3C compliance and WebAuthn authentication"
+type: changelog
+date: 2025-08-17T23:59:00Z
+changelog:
+  version: "0.11.3"
+  category: "DID"
+search:
+  tags:
+    - "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

docs/changelog/v0-11-4.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.11.4
+description: "Complete WebAuthn/FIDO2 implementation for passwordless authentication"
+type: changelog
+date: 2025-08-18T23:58:00Z
+changelog:
+  version: "0.11.4"
+  category: "WebAuthn"
+search:
+  tags:
+    - "FIDO2"
+---
+
+Complete WebAuthn/FIDO2 implementation for passwordless authentication (#215)
+
+- Full FIDO2 compliance with passwordless authentication
+- Hardware security key support
+- Biometric authentication integration

docs/changelog/v0-12-0.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.12.0
+description: "Add support for additional elliptic curves and JWK verification"
+type: changelog
+date: 2025-08-18T23:59:00Z
+changelog:
+  version: "0.12.0"
+  category: "Cryptography"
+search:
+  tags:
+    - "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

docs/changelog/v0-12-1.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.12.1
+description: "Replace InterchainTest with Starship-based E2E testing framework"
+type: changelog
+date: 2025-08-20T23:59:00Z
+changelog:
+  version: "0.12.1"
+  category: "Testing"
+search:
+  tags:
+    - "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

docs/changelog/v0-12-10.mdx

@@ -0,0 +1,19 @@
+---
+title: v0.12.10
+description: "Implement Service module capability system and parameters"
+type: changelog
+date: 2025-09-03T23:57:00Z
+changelog:
+  version: "0.12.10"
+  category: "Services"
+search:
+  tags:
+    - "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

docs/changelog/v0-12-11.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.12.11
+description: "WebAuthn attestation and verification improvements"
+type: changelog
+date: 2025-09-03T23:58:00Z
+changelog:
+  version: "0.12.11"
+  category: "WebAuthn"
+search:
+  tags:
+    - "Authentication"
+---
+
+WebAuthn attestation and verification improvements (#242)
+
+- Enhanced attestation verification logic
+- Improved security checks for authentication ceremonies
+- Refined credential validation mechanisms

docs/changelog/v0-12-3.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.12.3
+description: "Implement ICA Controller system in x/dex module for cross-chain DEX operations"
+type: changelog
+date: 2025-08-24T23:58:00Z
+changelog:
+  version: "0.12.3"
+  category: "ICA"
+search:
+  tags:
+    - "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

docs/changelog/v0-12-4.mdx

@@ -0,0 +1,15 @@
+---
+title: v0.12.4
+description: "Integrate Interchain Accounts for cross-chain DEX functionality"
+type: changelog
+date: 2025-08-24T23:59:00Z
+changelog:
+  version: "0.12.4"
+  category: "IBC"
+search:
+  tags:
+    - "DEX"
+---
+
+- Enhanced cross-chain interoperability for trading
+- IBC integration for decentralized exchange operations

docs/changelog/v0-12-5.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.12.5
+description: "Implement typed Protobuf events for x/did, x/dwn, and x/svc modules"
+type: changelog
+date: 2025-08-27T23:59:00Z
+changelog:
+  version: "0.12.5"
+  category: "Events"
+search:
+  tags:
+    - "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

docs/changelog/v0-12-6.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.12.6
+description: "Complete remaining event emissions for DID and DWN modules"
+type: changelog
+date: 2025-08-30T23:59:00Z
+changelog:
+  version: "0.12.6"
+  category: "Events"
+search:
+  tags:
+    - "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

docs/changelog/v0-12-7.mdx

@@ -0,0 +1,15 @@
+---
+title: v0.12.7
+description: "Implement module parameter validation and defaults"
+type: changelog
+date: 2025-09-02T23:59:00Z
+changelog:
+  version: "0.12.7"
+  category: "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

docs/changelog/v0-12-8.mdx

@@ -0,0 +1,20 @@
+---
+title: v0.12.8
+description: "Introduce key rotation events and IPFS status endpoint"
+type: changelog
+date: 2025-09-03T23:55:00Z
+changelog:
+  version: "0.12.8"
+  category: "DWN"
+search:
+  tags:
+    - "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

docs/changelog/v0-12-9.mdx

@@ -0,0 +1,19 @@
+---
+title: v0.12.9
+description: "Complete DID module WebAuthn and parameter implementation"
+type: changelog
+date: 2025-09-03T23:56:00Z
+changelog:
+  version: "0.12.9"
+  category: "DID"
+search:
+  tags:
+    - "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

docs/changelog/v0-13-0.mdx

@@ -0,0 +1,19 @@
+---
+title: v0.13.0
+description: "Fix cryptographic implementations and enable disabled tests"
+type: changelog
+date: 2025-09-03T23:59:00Z
+changelog:
+  version: "0.13.0"
+  category: "Cryptography"
+search:
+  tags:
+    - "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

docs/changelog/v0-13-2.mdx

@@ -0,0 +1,20 @@
+---
+title: v0.13.2
+description: "Implement OpenID Connect provider with WebAuthn in bridge handlers"
+type: changelog
+date: 2025-09-04T23:58:00Z
+changelog:
+  version: "0.13.2"
+  category: "Authentication"
+search:
+  tags:
+    - "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

docs/changelog/v0-13-3.mdx

@@ -0,0 +1,20 @@
+---
+title: v0.13.3
+description: "Consolidate deployment infrastructure with Docker Compose and enhance build targets"
+type: changelog
+date: 2025-09-04T23:59:00Z
+changelog:
+  version: "0.13.3"
+  category: "DevOps"
+search:
+  tags:
+    - "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

docs/changelog/v0-2-0.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.2.0
+description: "Implement DNS record verification with UCAN delegation for x/svc"
+type: changelog
+date: 2025-06-28T23:59:00Z
+changelog:
+  version: "0.2.0"
+  category: "DNS"
+search:
+  tags:
+    - "UCAN"
+---
+
+Implement DNS record verification with UCAN delegation for x/svc (#41)
+
+- DNS verification system
+- UCAN-based delegation
+- Service authentication

docs/changelog/v0-3-0.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.3.0
+description: "Migrate UCAN capability definitions to x/ucan module"
+type: changelog
+date: 2025-06-29T23:58:00Z
+changelog:
+  version: "0.3.0"
+  category: "UCAN"
+search:
+  tags:
+    - "Migration"
+---
+
+Migrate UCAN capability definitions to x/ucan module (#49)
+
+- UCAN module creation
+- Capability migration
+- Improved architecture

docs/changelog/v0-4-0.mdx

@@ -0,0 +1,19 @@
+---
+title: v0.4.0
+description: "W3C DID Controller with WebAuthn support and comprehensive testing improvements"
+type: changelog
+date: 2025-06-29T23:59:00Z
+changelog:
+  version: "0.4.0"
+  category: "DID"
+search:
+  tags:
+    - "WebAuthn"
+    - "Testing"
+---
+
+W3C DID Controller with WebAuthn support and comprehensive testing improvements (#52)
+
+- W3C DID controller implementation
+- WebAuthn authentication
+- Enhanced test coverage

docs/changelog/v0-4-1.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.4.1
+description: "Integrate Nebula UI Component Library"
+type: changelog
+date: 2025-06-30T23:57:00Z
+changelog:
+  version: "0.4.1"
+  category: "UI"
+search:
+  tags:
+    - "Components"
+---
+
+Integrate Nebula UI Component Library (#54)
+
+- UI component library integration
+- Reusable components
+- Design consistency

docs/changelog/v0-5-0.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.5.0
+description: "Implement x/ucan msgServer handlers with capability templates"
+type: changelog
+date: 2025-06-30T23:58:00Z
+changelog:
+  version: "0.5.0"
+  category: "UCAN"
+search:
+  tags:
+    - "Handlers"
+---
+
+Implement x/ucan msgServer handlers with capability templates (#55)
+
+- UCAN message handlers
+- Capability templates
+- Authorization framework

docs/changelog/v0-5-1.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.5.1
+description: "Enhance TUI Dashboard with real-time data visualization and testnet support"
+type: changelog
+date: 2025-06-30T23:59:00Z
+changelog:
+  version: "0.5.1"
+  category: "TUI"
+search:
+  tags:
+    - "Dashboard"
+---
+
+Enhance TUI Dashboard with real-time data visualization and testnet support (#59)
+
+- Real-time data visualization
+- Testnet dashboard support
+- Enhanced monitoring

docs/changelog/v0-6-0.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.6.0
+description: "Automated API Reference Generation for Cosmos Modules and Highway REST Service"
+type: changelog
+date: 2025-07-01T23:57:00Z
+changelog:
+  version: "0.6.0"
+  category: "API"
+search:
+  tags:
+    - "Documentation"
+---
+
+Automated API Reference Generation for Cosmos Modules and Highway REST Service (#62)
+
+- Automated API documentation
+- REST service documentation
+- Improved developer resources

docs/changelog/v0-6-1.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.6.1
+description: "ES-client protobuf generation"
+type: changelog
+date: 2025-07-01T23:58:00Z
+changelog:
+  version: "0.6.1"
+  category: "Protobuf"
+search:
+  tags:
+    - "Client"
+---
+
+ES-client protobuf generation (#63)
+
+- JavaScript client protobuf support
+- Improved client SDK
+- Better developer tools

docs/changelog/v0-7-0.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.7.0
+description: "Implement DWN module with enclave signing and DIF specification"
+type: changelog
+date: 2025-07-01T23:59:00Z
+changelog:
+  version: "0.7.0"
+  category: "DWN"
+search:
+  tags:
+    - "DIF"
+---
+
+Implement DWN module with enclave signing and DIF specification (#64)
+
+- Decentralized Web Node implementation
+- DIF specification compliance
+- Enclave-based signing

docs/changelog/v0-8-0.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.8.0
+description: "Integrate Trunk.io for code quality and linting"
+type: changelog
+date: 2025-07-02T23:58:00Z
+changelog:
+  version: "0.8.0"
+  category: "Quality"
+search:
+  tags:
+    - "Linting"
+---
+
+Integrate Trunk.io for code quality and linting (#65)
+
+- Trunk.io integration
+- Automated code quality checks
+- Enhanced linting rules

docs/changelog/v0-8-11.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.8.11
+description: "Complete shadcn/TemplUI migration from NebulaUI"
+type: changelog
+date: 2025-07-04T23:59:00Z
+changelog:
+  version: "0.8.11"
+  category: "UI"
+search:
+  tags:
+    - "Migration"
+---
+
+Complete shadcn/TemplUI migration from NebulaUI (#79)
+
+- UI library migration
+- Modern component system
+- Improved styling

docs/changelog/v0-8-12.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.8.12
+description: "Implement Rybbit analytics and update documentation site styling"
+type: changelog
+date: 2025-07-05T23:59:00Z
+changelog:
+  version: "0.8.12"
+  category: "Analytics"
+search:
+  tags:
+    - "Documentation"
+---
+
+Implement Rybbit analytics and update documentation site styling (#80)
+
+- Analytics integration
+- Documentation improvements
+- Better user insights

docs/changelog/v0-8-2.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.8.2
+description: "Enhanced documentation landing page with custom branding"
+type: changelog
+date: 2025-07-02T23:59:00Z
+changelog:
+  version: "0.8.2"
+  category: "Documentation"
+search:
+  tags:
+    - "Branding"
+---
+
+Enhanced documentation landing page with custom branding (#69)
+
+- Custom branding implementation
+- Improved documentation UI
+- Better user experience

docs/changelog/v0-9-0.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.9.0
+description: "Refactor x/dwn module structure and integrate WebAssembly motor client"
+type: changelog
+date: 2025-07-06T23:59:00Z
+changelog:
+  version: "0.9.0"
+  category: "DWN"
+search:
+  tags:
+    - "WASM"
+---
+
+Refactor x/dwn module structure and integrate WebAssembly motor client (#81)
+
+- Major DWN module refactoring
+- WASM motor client integration
+- Enhanced documentation

docs/changelog/v0-9-10.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.9.10
+description: "Implement UCANKeeper interface methods and centralize error handling"
+type: changelog
+date: 2025-07-18T23:56:00Z
+changelog:
+  version: "0.9.10"
+  category: "UCAN"
+search:
+  tags:
+    - "Error Handling"
+---
+
+Implement UCANKeeper interface methods and centralize error handling (#112)
+
+- UCAN keeper implementation
+- Centralized error management
+- Improved code maintainability

docs/changelog/v0-9-11.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.9.11
+description: "Implement ServiceKeeper interface methods in x/svc keeper"
+type: changelog
+date: 2025-07-18T23:57:00Z
+changelog:
+  version: "0.9.11"
+  category: "Service"
+search:
+  tags:
+    - "Keeper"
+---
+
+Implement ServiceKeeper interface methods in x/svc keeper (#113)
+
+- Complete service keeper implementation
+- Core service functionality
+- Module integration

docs/changelog/v0-9-14.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.9.14
+description: "Implement DIDKeeper interface for x/svc module"
+type: changelog
+date: 2025-07-18T23:58:00Z
+changelog:
+  version: "0.9.14"
+  category: "Service"
+search:
+  tags:
+    - "DID"
+---
+
+Implement DIDKeeper interface for x/svc module (#116)
+
+- DID integration for services
+- Identity-based service management
+- Enhanced authentication

docs/changelog/v0-9-15.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.9.15
+description: "Implement UCANKeeper interface for x/svc module"
+type: changelog
+date: 2025-07-18T23:59:00Z
+changelog:
+  version: "0.9.15"
+  category: "Service"
+search:
+  tags:
+    - "UCAN"
+---
+
+Implement UCANKeeper interface for x/svc module (#117)
+
+- Service module UCAN support
+- Permission management
+- Improved security model

docs/changelog/v0-9-16.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.9.16
+description: "Implement UCANKeeper interface for x/dwn module"
+type: changelog
+date: 2025-07-20T23:55:00Z
+changelog:
+  version: "0.9.16"
+  category: "DWN"
+search:
+  tags:
+    - "UCAN"
+---
+
+Implement UCANKeeper interface for x/dwn module (#119)
+
+- UCAN integration for DWN
+- Capability-based permissions
+- Enhanced authorization

docs/changelog/v0-9-17.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.9.17
+description: "Implement ServiceKeeper interface for x/dwn module"
+type: changelog
+date: 2025-07-20T23:56:00Z
+changelog:
+  version: "0.9.17"
+  category: "DWN"
+search:
+  tags:
+    - "Service"
+---
+
+Implement ServiceKeeper interface for x/dwn module (#120)
+
+- Service abstraction layer
+- Improved module interactions
+- Enhanced modularity

docs/changelog/v0-9-18.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.9.18
+description: "Improve service validation and UCAN integration"
+type: changelog
+date: 2025-07-20T23:57:00Z
+changelog:
+  version: "0.9.18"
+  category: "Service"
+search:
+  tags:
+    - "UCAN"
+---
+
+Improve service validation and UCAN integration (#121)
+
+- Enhanced service validation logic
+- UCAN capability improvements
+- Better error handling

docs/changelog/v0-9-19.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.9.19
+description: "Add cross-module keeper integration tests and optimize CI performance"
+type: changelog
+date: 2025-07-20T23:58:00Z
+changelog:
+  version: "0.9.19"
+  category: "Testing"
+search:
+  tags:
+    - "CI"
+---
+
+Add cross-module keeper integration tests and optimize CI performance (#122)
+
+- Cross-module testing framework
+- CI pipeline optimization
+- Better test coverage

docs/changelog/v0-9-20.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.9.20
+description: "Add transaction building framework and streamline release process"
+type: changelog
+date: 2025-07-20T23:59:00Z
+changelog:
+  version: "0.9.20"
+  category: "Transactions"
+search:
+  tags:
+    - "Release"
+---
+
+Add transaction building framework and streamline release process (#123)
+
+- Comprehensive transaction builder
+- Automated release pipeline
+- Improved developer tools

docs/changelog/v0-9-22.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.9.22
+description: "Implement vault export/import with IPFS encryption"
+type: changelog
+date: 2025-07-21T23:58:00Z
+changelog:
+  version: "0.9.22"
+  category: "Vault"
+search:
+  tags:
+    - "IPFS"
+---
+
+Implement vault export/import with IPFS encryption (#125)
+
+- IPFS-based vault backup
+- Encrypted vault exports
+- Decentralized storage integration

docs/changelog/v0-9-3.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.9.3
+description: "Centralize vault actor system and optimize plugin management"
+type: changelog
+date: 2025-07-09T23:59:00Z
+changelog:
+  version: "0.9.3"
+  category: "Vault"
+search:
+  tags:
+    - "Actor"
+---
+
+Centralize vault actor system and optimize plugin management (#83)
+
+- Actor system centralization
+- Plugin optimization
+- Performance improvements

docs/changelog/v0-9-4.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.9.4
+description: "Update testnet configuration for DAO governance"
+type: changelog
+date: 2025-07-14T23:59:00Z
+changelog:
+  version: "0.9.4"
+  category: "Testnet"
+search:
+  tags:
+    - "DAO"
+---
+
+Update testnet configuration for DAO governance (#84)
+
+- DAO governance integration
+- Testnet parameter updates
+- Governance readiness

docs/changelog/v0-9-5.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.9.5
+description: "Enable DWN vault spawning via query API and add comprehensive tests"
+type: changelog
+date: 2025-07-15T23:59:00Z
+changelog:
+  version: "0.9.5"
+  category: "DWN"
+search:
+  tags:
+    - "Vault"
+---
+
+Enable DWN vault spawning via query API and add comprehensive tests (#98)
+
+- Query-based vault creation
+- Comprehensive test suite
+- API improvements

docs/changelog/v0-9-6.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.9.6
+description: "Introduce VaultKeeper interface for enhanced modularity"
+type: changelog
+date: 2025-07-16T23:59:00Z
+changelog:
+  version: "0.9.6"
+  category: "Vault"
+search:
+  tags:
+    - "Interface"
+---
+
+Introduce VaultKeeper interface for enhanced modularity (#99)
+
+- Vault abstraction layer
+- Improved code organization
+- Better testability

docs/changelog/v0-9-8.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.9.8
+description: "Implement wallet derivation and keeper interface architecture"
+type: changelog
+date: 2025-07-18T23:54:00Z
+changelog:
+  version: "0.9.8"
+  category: "Wallet"
+search:
+  tags:
+    - "Architecture"
+---
+
+Implement wallet derivation and keeper interface architecture (#110)
+
+- HD wallet derivation
+- Keeper interface design
+- Improved wallet architecture

docs/changelog/v0-9-9.mdx

@@ -0,0 +1,18 @@
+---
+title: v0.9.9
+description: "Implement VerifyDIDDocumentSignature method with multi-algorithm support"
+type: changelog
+date: 2025-07-18T23:55:00Z
+changelog:
+  version: "0.9.9"
+  category: "DID"
+search:
+  tags:
+    - "Signatures"
+---
+
+Implement VerifyDIDDocumentSignature method with multi-algorithm support (#111)
+
+- Multi-algorithm signature verification
+- Ed25519, ECDSA, RSA support
+- Enhanced DID security

docs/economics/distribution.mdx

@@ -0,0 +1,306 @@
+---
+title: Distribution
+description: SNR token distribution model, allocation strategy, and economic distribution mechanisms
+icon: "chart-pie"
+sidebar:
+  label: "Supply & Distribution"
+---
+
+## Overview
+
+The SNR token distribution is designed to balance immediate network needs with long-term sustainability, ensuring fair allocation across stakeholders while maintaining sufficient reserves for ecosystem growth.
+
+**Total Supply: 1,000,000,000 SNR**
+
+:::note
+Token distribution follows a carefully planned vesting schedule to prevent
+market manipulation and ensure aligned incentives across all participants.
+:::
+
+## Supply Dynamics
+
+### Circulating Supply Factors
+
+The circulating token supply depends on several key factors:
+
+<CardGroup>
+  <Card title="Initial Circulation">
+    200M SNR at genesis (20% of total supply)
+  </Card>
+  <Card title="Minted Tokens">
+    New tokens created through inflation for rewards and subsidies
+  </Card>
+  <Card title="Vesting Releases">
+    Scheduled releases from locked allocations over time
+  </Card>
+  <Card title="Staked Tokens">
+    Tokens locked in staking reducing effective circulation
+  </Card>
+</CardGroup>
+
+### Token Velocity
+
+Token velocity measures how frequently tokens change hands and directly impacts token value:
+
+```math
+\text{Token Value} = \frac{\text{Economic Activity}}{\text{Circulating Supply} \times \text{Velocity}}
+```
+
+## Allocation Strategy
+
+### Core Allocations
+
+The token distribution prioritizes long-term network health through strategic allocations:
+
+1. **Community & Ecosystem** (35% - 350M SNR)
+   - Airdrop Program: 100M SNR (10%)
+   - Testnet Incentives: 50M SNR (5%)
+   - Staking Rewards Pool: 100M SNR (10%)
+   - Ecosystem Grants: 100M SNR (10%)
+
+2. **Team & Advisors** (20% - 200M SNR)
+   - Team Allocation: 150M SNR (15%)
+   - Advisors: 50M SNR (5%)
+
+3. **Investors** (25% - 250M SNR)
+   - Seed Round: 75M SNR (7.5%)
+   - Series A: 100M SNR (10%)
+   - Strategic Round: 75M SNR (7.5%)
+
+4. **Foundation Treasury** (15% - 150M SNR)
+   - Operations: 75M SNR (7.5%)
+   - Reserve Fund: 75M SNR (7.5%)
+
+5. **Validator Incentives** (5% - 50M SNR)
+   - Genesis Validators: 30M SNR (3%)
+   - Delegation Program: 20M SNR (2%)
+
+### Vesting Schedules
+
+:::warning
+All non-circulating allocations follow strict vesting schedules to ensure
+gradual market entry and prevent supply shocks.
+:::
+
+#### Team Vesting
+
+- **Team**: 12-month cliff, 48-month linear vest
+- **Advisors**: 6-month cliff, 24-month linear vest
+- No transfers until cliff periods expire
+
+#### Investor Vesting
+
+- **Seed Round**: 6-month cliff, 36-month linear vest
+- **Series A**: 3-month cliff, 24-month linear vest
+- **Strategic Round**: 25% immediate, remainder over 18 months
+
+#### Community Vesting
+
+- **Airdrop**: 25% immediate, 75% over 12 months
+- **Testnet**: Distribution over 6-month testnet period
+- **Ecosystem Grants**: Project milestone-based releases
+
+#### Foundation Vesting
+
+- **Operations**: 10% at genesis, 90% over 5 years
+- **Reserve Fund**: Minimum 3 years lockup, governance approval required
+
+## Inflation Mechanism
+
+### Reward Distribution
+
+The network implements controlled inflation to incentivize participation:
+
+<CardGroup>
+  <Card title="Validator Rewards">
+    Block rewards for consensus participation distributed pro-rata to stake
+  </Card>
+  <Card title="Highway Services">
+    Compensation for off-chain computation, storage, and routing services
+  </Card>
+  <Card title="Governance Rewards">
+    Incentives for proposal creation and voting participation
+  </Card>
+</CardGroup>
+
+### Inflation Schedule
+
+**Year 1**: 15% inflation (aggressive growth)
+- Focus on network bootstrapping
+- High rewards for early adopters
+
+**Year 2**: 12% inflation (continued expansion)
+- Stabilization period begins
+- Balanced growth incentives
+
+**Year 3**: 9% inflation (stabilization)
+- Network maturation
+- Sustainable reward levels
+
+**Year 4+**: 7% inflation (long-term sustainability)
+- Minimal dilution
+- Self-sustaining economics
+
+## Economic Safeguards
+
+### Anti-Manipulation Measures
+
+1. **Vesting Cliffs**: Prevent immediate dumps from large holders
+2. **Staking Lockups**: Reduce liquid supply through validator requirements
+3. **Governance Delays**: Time-locked treasury withdrawals
+4. **Slashing Penalties**: Discourage malicious validator behavior
+
+### Supply Controls
+
+The network implements several mechanisms to manage token supply:
+
+- **Fee Burning**: 50% of transaction fees burned (deflationary)
+- **Treasury Management**: Governance-controlled minting caps
+- **Dynamic Rewards**: Adjustment based on network participation
+- **Lock Incentives**: Higher rewards for longer staking periods
+
+### Centralization Risks
+
+- No single entity controls >20% at genesis
+- Team tokens have longest vesting (4 years)
+- Foundation treasury requires governance approval
+- Validator set caps prevent concentration
+
+### Market Stability
+
+- Staggered vesting prevents supply shocks
+- Fee burning provides deflationary pressure
+- Utility demand from identity services
+- Cross-chain value capture mechanisms
+
+## Token Utility & Value Accrual
+
+### Primary Utilities
+
+<CardGroup>
+  <Card title="Network Security">
+    Staking for validation and delegation
+  </Card>
+  <Card title="Governance">
+    Voting on protocol upgrades and parameters
+  </Card>
+  <Card title="Transaction Fees">
+    Gas payments for network operations
+  </Card>
+  <Card title="Identity Services">
+    Premium features and API access
+  </Card>
+</CardGroup>
+
+### Value Accrual Mechanisms
+
+1. **Fee Burning**: 50% of transaction fees burned (deflationary)
+2. **Staking Yield**: 7-15% APR depending on network participation
+3. **Identity Revenue**: Enterprise licensing fees distributed to stakers
+4. **Cross-chain Value**: IBC transfer fees and bridge operations
+
+### Staking Targets
+
+- **Target staking ratio**: 65%
+- **Validator set**: 50-100 active validators
+- **Minimum stake**: 1M SNR (0.1% of supply)
+- **Delegation minimum**: 1 SNR (accessible to all)
+
+### Vesting Schedule Overview
+
+| Category | Immediate | 6 Months | 12 Months | 24 Months | 36 Months | 48 Months |
+|----------|-----------|----------|-----------|-----------|-----------|-----------|
+| Airdrop | 25% | 50% | 75% | 100% | - | - |
+| Team | 0% | 0% | 12.5% | 37.5% | 62.5% | 100% |
+| Seed Investors | 0% | 0% | 16.7% | 50% | 83.3% | 100% |
+| Series A | 0% | 25% | 50% | 100% | - | - |
+| Foundation | 10% | 28% | 46% | 64% | 82% | 100% |
+
+:::success
+The distribution model prioritizes network security, ecosystem growth, and
+fair participant rewards while maintaining economic sustainability.
+:::
+
+## Distribution Timeline
+
+### Pre-Launch (Months -6 to 0)
+
+- Team allocation locked
+- Investor funds raised
+- Testnet incentives distributed
+- Airdrop snapshot taken
+
+### Genesis (Month 0)
+
+- 200M SNR circulating supply
+- Genesis validators receive allocation
+- Foundation treasury initialized
+- Staking rewards begin
+
+### Year 1 (Months 1-12)
+
+- Airdrop vesting releases 75M SNR
+- Team cliff expires, vesting begins
+- Series A completes vesting
+- Ecosystem grants distributed
+
+### Year 2-3 (Months 13-36)
+
+- Seed round completes vesting
+- Team reaches 62.5% vested
+- Foundation operations fully unlocked
+- Validator program matured
+
+## Economic Incentives
+
+### Genesis Validator Program
+
+- **Genesis Validators**: 30M SNR (3%)
+- 50 validators × 600,000 SNR each
+- 24 months minimum staking lockup
+- 99%+ uptime and governance participation required
+
+### Delegation Program
+
+- **Foundation Delegations**: 20M SNR (2%)
+- 6-month renewable terms
+- Performance-based allocation
+- Support for high-performing validators
+
+### Maturity Phase (Year 3+)
+
+- Stabilized inflation rate
+- Self-sustaining economics
+- Community-driven allocation
+
+## Success Metrics
+
+### Year 1 Targets
+
+- 50% of supply staked
+- 50+ active validators
+- 100k+ active addresses
+- $10M+ in identity service revenue
+
+### Year 3 Targets
+
+- 65% of supply staked
+- 75+ active validators
+- 1M+ active addresses
+- $100M+ total value locked
+
+### Long-term Vision (5+ years)
+
+- Self-sustaining network economics
+- Deflationary token model
+- Industry-standard identity infrastructure
+- Billion-dollar ecosystem value
+
+## Transparency Commitments
+
+All token distributions are:
+
+- Publicly verifiable on-chain
+- Subject to regular audits
+- Reported in quarterly updates
+- Governed by smart contracts

docs/economics/governance.mdx

@@ -0,0 +1,99 @@
+---
+title: "Governance"
+description: "Governance is the process of making decisions on behalf of a group of people or organization"
+icon: "landmark"
+sidebar:
+  label: "Protocol Governance"
+---
+
+The Demand is rooted from participation in the governance process, determining upgrades to the protocol or allocation of resources, and supply is the result of the tokens eligible to participate in the governance process.
+On Sonr we will be leveraging a **delegate stake** mechanism in order to **optimize buy-in** for users in the network. It imposes an **excess opportunity cost** if **slashing** is implemented.
+
+**Seven elements of economic design for governance**
+
+1. Scope of Decisions
+2. Stakeholders
+3. Policy Research & Development
+4. Proposal Process
+5. Information Distribution Systems
+6. Decision Making Procedures
+7. Implementation & Property Rights
+
+## Yearly Governance Cycle
+
+- Two General Elections for proposals yearly
+- Proposals need at least 20% of all validator approval to move into general election
+- 51% of General Vote required for proposal to pass
+- Emergency Voting sessions can be called if requested by 51% of Governance Participants
+
+### ☀️ Summer Cycle
+
+|                               | Start Date | End Date |
+| ----------------------------- | ---------- | -------- |
+| Validator Vetting             | 5/17       | 5/31     |
+| Proposals Posted              | 6/1        |          |
+| General Election of Proposals | 6/2        | 6/15     |
+| Results Posted                | 6/16       |          |
+
+### ❄️ Winter Cycle
+
+|                               | Start Date | End Date |
+| ----------------------------- | ---------- | -------- |
+| Validator Vetting             | 11/17      | 11/31    |
+| Proposals Posted              | 12/1       |          |
+| General Election of Proposals | 12/2       | 12/15    |
+| Results Posted                | 12/16      |          |
+
+## First Rollout Phase
+
+These are the measures the core Sonr team will be undertaking prior and during test-net deployment.
+
+### Establish Community
+
+Build a loyal community of token holders that represent our platforms stakeholder groups.
+
+- All of our existing token holders (this includes our founder and early investors) will be staking their Sonr Token in order to be incentivized to hold tokens and participate in voting
+- We will be actively networking with DeFi projects, blockchain service providers, and etc. in order to participate
+
+### Build Dashboards
+
+We are under the process of creating a [dashboard](https://sonrscan.io) in order to provide key metrics to our stakeholders
+
+- **Technology**: Pricing, total fees paid, total storage used, uptime
+- **Governance**: Identities, proposal outcomes, community participation
+
+### Polling System
+
+Our initial polling system will be token weighted and not enforceable, in order to build engagement.
+
+- Users will submit qualitative updates to the system and have them up/downvoted
+- The core team will then assess the submissions and select viable community suggestions into upgrades
+  - Along side this, our team will locate and commission the development of a proposal for any technical upgrades without enforceable code proposals
+  - We will be able to provide clarity, external security, and in applicable cases the economic evaluation from the impacts of proposals to the community.
+
+## Second Rollout Phase
+
+Phase 2 will be underway in the months prior to main-net deployment, along with an extensive security audit.
+
+### On-Chain Execution
+
+We will be introducing an on-chain, executable code-based governance system in stages with majority rule voting.
+
+**Stage 1:** Grants Program
+
+- Incorporate community voting for grant recipient selection
+- Allow users to submit proposals for grant allocation
+
+**Stage 2:** Subsidies and Rewards
+
+- Proposals to update subsidies and rewards can be submitted by Core Sonr Team or third parties
+- Core Team will be responsible for considering funding security, and economic audits for proposals
+
+**Stage 3:** Technical Upgrades
+
+- These include pricing, security, and bug fixes
+- Proposals will be spearheaded by the Sonr Team and/or its delegates
+
+### Maintenance
+
+When on-chain governance has come to fruition, the core Sonr team will be also maintaining the polling-based system with subsidized development to minimize barrier to entry. This will be incorporating governance within the Motor Nebula Widget itself.

docs/economics/meta.ts

@@ -0,0 +1,15 @@
+import { defineMeta } from "blume";
+
+export default defineMeta({
+  "title": "Token Economics",
+  "icon": "coins",
+  "collapsed": true,
+  "pages": [
+    "values",
+    "utility",
+    "staking",
+    "rewards",
+    "governance",
+    "distribution"
+  ]
+});

docs/economics/rewards.mdx

@@ -0,0 +1,25 @@
+---
+title: "Rewards"
+description: "Incentivizing the Sonr Ecosystem"
+icon: "gem"
+sidebar:
+  label: "Network Rewards"
+---
+
+In order to maximize buy-in and network availability for the Sonr ecosystem, we will be implementing an empirical Token Rewards mechanism. Rewards are a way to create inflation in order to dilute the token value, resulting in an affordable onboarding and operational experience for the end user. The goal behind Sonr Token rewards is to subsidize Highway based computation, in order to promote value creation and platform growth.
+
+### Governance Participation
+
+At the time of Main-net launch, phase one of the Sonr governance rollout will be implemented and will result in a set of rewards for participants.
+
+**Submission of Proposals**
+
+Users will be incentivized to submit blockchain improvement or grant proposals to be reviewed by voting participants. In order to prevent game from low quality and out of scope proposals, a clear-cut submission and evaluation process will be put into place on a public facing FAQ website.
+
+- Proposers are required to stake before submission — _“Application Fee”_
+
+**Proposal Voting**
+
+In order to prevent innovation from halting on the Sonr ecosystem, we incentivize all staked users to participate in the polling process for community submitted proposals. Users are then rewarded for good-faith participation in voting, while also sustaining momentum.
+
+- Existing Stakeholders are rewarded for good-faith participation in voting