Skip to main content

DIG Handles

💜 Support the DIG Network

Help build the future of decentralized storage! The DIG Network is an open-source project that needs community support to continue development.

💜 Support the Project → - Donate crypto, buy NFTs, or sponsor development

Overview​

DIG Handles provide a human-readable domain system (*.dig) for the DIG Network, linking memorable names to DataStores while creating economic signals for content value. Based on the XCHandles architecture, handles serve as market-driven indicators that help validators prioritize high-value content for propagation and rewards.

Technical Architecture​

Registry Design​

DIG Handles fork the XCHandles decentralized registry system:

interface DIGHandle {
  // Core fields
  handleName: string;              // e.g., "myproject.dig"
  owner: bytes32;                  // Chia public key
  linkedDataStore: bytes32;        // Associated DataStore ID
  registrationDate: uint64;        // Unix timestamp
  expirationDate: uint64;          // Unix timestamp
  registrationFee: uint64;         // DIG tokens paid
  
  // Metadata
  metadata: {
    category: string;              // Content category
    priority: uint8;               // Propagation priority (0-255)
    customFields: Map<string, any>; // Extensible metadata
  };
}

Smart Contract Operations​

Inherited from XCHandles with DIG-specific adaptations:

# Primary actions
register_action(handle, datastore_id, payment)    # Register new handle
extend_action(handle, payment)                     # Extend expiration
update_action(handle, new_datastore_id)           # Update association
transfer_action(handle, new_owner)                 # Transfer ownership
expire_action(handle)                             # Process expiration

# Query operations
query_handle(name) -> DIGHandle
query_by_datastore(id) -> List[DIGHandle]
query_by_owner(address) -> List[DIGHandle]

Economic Model​

Pricing Tiers​

Illustrative Example

The following pricing tiers are provided as an illustrative example of how handle costs could create tiered value signals. Actual pricing will be determined by the DAO governance process.

Handle costs create tiered value signals:

Length  | Cost (DIG) | Reward Multiplier | Use Case
--------|------------|-------------------|----------
3 char  | 5000       | 5x               | Premium brands
4 char  | 1000       | 4x               | Major projects
5 char  | 200        | 3x               | Standard projects
6 char  | 40         | 2x               | Regular content
7 char  | 8          | 1.5x             | Basic content
8+ char | 1          | 1x               | Long-tail content

Note: These values are illustrative. Actual pricing and multipliers will be set through DAO governance.

Fee Distribution​

Current Model (Validator Multisig):

Registration Fee → Validator Operations (100%)

Future DAO Model:

Registration Fee → {
  TBD → Storage Provider Rewards
  TBD → Validator Compensation  
  TBD → DAO Treasury
  TBD → Protocol Development
}

Value Signaling​

Economic commitment indicates content value:

  • Registration Cost: Higher cost = stronger value signal
  • Renewal Commitment: Ongoing payments = sustained value
  • Market Discovery: Price reflects perceived utility
  • Network Priority: Handled content receives priority

Network Integration​

Propagation Trigger​

Handle registration is the first requirement for content distribution, followed by CapsuleStakeCoins:

STEP 1: Register Handle → Link to DataStore
                              ↓
STEP 2: Create CapsuleStakeCoins → Per-capsule collateral commitment
                         ↓
Network Response:
3. DIG Nodes discover → Economic value signals (handle tier + collateral)
                         ↓
4. Storage Providers → Download and plot content for rewards
                         ↓
5. PlotCoin Creation → Proof of Living Storage commitments
                         ↓
6. Witness Validation → Validate storage against DIG Nodes
                         ↓
7. Reward Distribution → Based on handle tier and successful validation

Reward Multipliers​

Handle registration tier and capsule size both affect storage rewards:

# Note: This is an illustrative example. Actual multipliers will be set by DAO governance.
def calculate_rewards(base_reward, handle_tier, capsule_size_mb):
    # Handle tier multipliers
    handle_multipliers = {
        3: 5.0,   # 3-char handles
        4: 4.0,   # 4-char handles
        5: 3.0,   # 5-char handles
        6: 2.0,   # 6-char handles
        7: 1.5,   # 7-char handles
        8: 1.0    # 8+ char handles
    }
    
    # Capsule size multipliers (larger capsules = higher rewards)
    size_multipliers = {
        0.25: 1.0,    # 256KB capsules
        1.0: 1.2,     # 1MB capsules  
        10.0: 1.5,    # 10MB capsules
        100.0: 2.0,   # 100MB capsules
        1000.0: 3.0   # 1000MB capsules
    }
    
    tier = len(handle) if len(handle) <= 8 else 8
    handle_multiplier = handle_multipliers.get(tier, 1.0)
    size_multiplier = size_multipliers.get(capsule_size_mb, 1.0)
    
    return base_reward * handle_multiplier * size_multiplier

Handle Management​

Lifecycle Operations​

Registration:

  • Requires DIG token payment
  • Links to specific DataStore
  • Creates on-chain record
  • Triggers propagation signals

Renewal:

  • Extend before expiration
  • Prepayment supported
  • Anyone can renew (enables community funding)
  • Maintains propagation incentives

Transfer:

  • Change ownership atomically
  • Preserves handle history
  • Updates linked DataStore
  • Maintains tier benefits

Expiration Handling​

Handle Expires → Grace Period (30 days) → Available for Registration
                        ↓
                 Loss of Benefits:
                 - No storage rewards
                 - No propagation priority
                 - Handle can be claimed

Community Funding​

Decentralized Renewal​

Any party can renew handles, enabling:

interface RenewalFunding {
  source: "nft_royalties" | "dao_treasury" | "crowdfund" | "defi_fees";
  amount: uint64;
  executor_tip: uint64;  // Incentive for manual execution
  auto_renew: boolean;   // Future feature
}

Implementation Example:

# NFT collection funds handle renewal
def fund_handle_renewal(handle_name, funding_source):
    renewal_cost = get_renewal_cost(handle_name)
    executor_tip = renewal_cost * 0.05  # 5% tip
    
    if funding_source.balance >= renewal_cost + executor_tip:
        execute_renewal(handle_name, renewal_cost, executor_tip)
        funding_source.deduct(renewal_cost + executor_tip)

Security Model​

Anti-Squatting Mechanisms​

  • Economic Cost: Real DIG token requirement
  • Ongoing Commitment: Renewal costs prevent hoarding
  • Market Pricing: Valuable names become expensive
  • Community Override: Anyone can support valuable content

Registry Security​

  • Singleton Pattern: Single source of truth on-chain
  • Cryptographic Binding: Handles bound to owner keys
  • Atomic Operations: All updates are atomic
  • Audit Trail: Complete history preserved

Technical Specifications​

Registry Singleton​

(mod (CURRENT_STATE ACTION PAYMENT)
  (defun process-action (state action payment)
    (cond
      ((= action 'register) (register-handle state payment))
      ((= action 'extend) (extend-handle state payment))
      ((= action 'update) (update-handle state))
      ((= action 'transfer) (transfer-handle state))
      ((= action 'expire) (expire-handle state))))
  
  (process-action CURRENT_STATE ACTION PAYMENT))

Integration Points​

DataStore Integration:

  • Direct linking to DataStore IDs
  • Merkle root verification
  • Version tracking support

PlotCoin Integration:

  • Handle tier affects reward calculations
  • Propagation priority based on tier
  • Automatic discovery by storage providers

Validator Integration:

  • Query handle registry for value signals
  • Prioritize handled content
  • Distribute tier-based rewards

Performance Characteristics​

  • Registration Time: ~30 seconds (1 block confirmation)
  • Query Performance: O(1) by handle name
  • Bulk Operations: Batch support for efficiency
  • Storage Overhead: ~500 bytes per handle

Best Practices​

Handle Strategy​

  1. Naming Convention: Use descriptive, memorable names
  2. Tier Selection: Balance cost vs. reward benefits
  3. Renewal Planning: Prepay for critical handles
  4. Portfolio Management: Diversify handle holdings

Integration Guidelines​

  1. Value Assessment: Register handles for genuinely valuable content
  2. Community Building: Enable community renewal funding
  3. Monitoring: Track handle expiration dates
  4. Documentation: Document handle-datastore mappings