# What is Lynx?

Published: October 2024 | Last updated: January 2026

### **Decentralized Storage Platform for Permanent Data Preservation**

Lynx is a decentralized, permanent data storage platform. By operating multiple blockchain networks in parallel, Lynx provides scalable, low-cost storage for your most important digital assets—ensuring your data remains accessible, unalterable, and secure for centuries without subscriptions, paywalls, or ongoing monthly fees.

<img src="https://get.clevver.org/b34219dfcfa28f028c152c6f120f96a768451a28d8f26872a4104819802f1d50.png" alt="Lynx logo stored at clevver.org" width="563">

### **A Platform, Not Just a Blockchain**

Rather than limiting storage capacity to a single blockchain, Lynx operates as a comprehensive storage platform managing over 400 independent blockchain networks. This multi-chain architecture allows Lynx to handle extraordinary volumes of data storage requests simultaneously, far beyond what any single blockchain could support.

The primary Lynx blockchain serves as the flagship network, with hundreds of additional blockchain networks ready to receive data through an intelligent queue management system. Each network operates independently while contributing to the platform's collective storage infrastructure, creating a distributed preservation system of unprecedented scale and durability.

### **How Lynx Preserves Your Data**

Unlike traditional cloud storage services that can shut down, change terms, or lock you out of your own files, Lynx uses distributed ledger technology to create permanent records that no single entity controls. Your documents, images, and digital assets become part of an immutable archive that cannot be deleted, edited, or removed by anyone—including governments, corporations, bad actors, or Lynx itself.

The Lynx platform operates through energy-efficient Proof of Stake consensus across all its networks, dramatically reducing environmental impact compared to traditional data centers and Proof of Work blockchain systems. This sustainable approach ensures the platform can preserve your data reliably for over 250 years without unsustainable energy demands.

### **Massive, Scalable Storage Capacity**

Through its multi-blockchain architecture, the Lynx platform provides virtually unlimited storage expansion capability. The network of over 400 chains collectively handles hundreds of terabytes of data annually. As storage demand grows, additional blockchain networks can be deployed seamlessly to expand platform capacity without disrupting existing operations.

### **Free, Permanent Access**

One of Lynx's most powerful features is perpetual, barrier-free access to stored data across all platform networks. You pay a small, one-time fee to store your information permanently, but there are never any charges for retrieving or accessing that data—today, next year, or decades from now.

Whether you need to download an encrypted document you stored years ago or programmatically access data through the Lynx RPC or Clevver API, your content remains available at any time without subscription fees, usage charges, or access restrictions.

### **Why a Multi-Chain Platform?**

Individual blockchains face inherent scaling limitations in how much data they can process within a given timeframe. By operating multiple blockchain networks under a unified platform with intelligent queue management, Lynx eliminates these constraints while maintaining the security and permanence advantages of blockchain technology. This architecture provides:

* **High-speed processing** - Distribute data across hundreds of chains simultaneously
* **Burst capacity handling** - Absorb massive storage requests without delays
* **Unlimited scalability** - Add new blockchain networks as capacity needs grow
* **Network redundancy** - Multiple chains ensure platform resilience
* **No recurring fees** - Pay once to store, never pay monthly subscription costs
* **Future-proof architecture** - Platform can evolve without migrating existing data

### **Why This Matters**

Traditional storage solutions carry ongoing risks: companies go out of business, pricing models change, unacceptable terms of service appear, platforms shut down, or content disappears behind paywalls. Single-blockchain storage solutions face speed and capacity bottlenecks that limit their practical utility for large-scale applications.

Lynx eliminates these uncertainties by creating a trustless preservation system where your data's accessibility is mathematically guaranteed across a distributed network of blockchain ledgers, while the multi-chain queue system ensures your data is stored quickly regardless of network demand.

Your critical information—family archives, business records, research data, creative works—deserves storage that's as permanent as the content itself, and fast enough to handle real-world usage demands. Lynx delivers that assurance through decentralized technology designed to outlast any single organization, platform, or business model.


# Technical Evolution and Architecture Overview

Published: October 2024 | Last updated: January 2026

### Executive Summary

Lynx represents a significant evolution in blockchain technology, transforming from a traditional cryptocurrency into an advanced data storage platform. This document outlines the technical progression, architectural innovations, and current capabilities of the Lynx blockchain platform.

### Historical Evolution

#### Origins and Early Development (2013-2017)

Originally launched as Kittehcoin (MEOW) in 2013, the project emerged during the early expansion of alternative cryptocurrencies. Initial technical challenges led to a comprehensive rebuild under new leadership in 2017, establishing the foundation for what would become Lynx.

#### Technical Migration Timeline

{% @mermaid/diagram content="timeline
title Lynx Technical Evolution
2013 : Kittehcoin Launch
: Initial cryptocurrency implementation
2017 : Technical Rebuild
: Migration to Litecoin codebase
: Launch as Lynx
2019 : Data Storage Innovation
: API Implementation
: Enhanced storage capabilities
2024 : Migration to Bitcoin v25 codebase
: Transition to PoS
: RPC Implementation
: 5x Storage Expansion
2025 : Unlimited Storage Architecture expansion
: Encrypted data storage implementation" %}

The platform's transition from Hierarchical Proof of Work (HPoW) to Linear Weight Moving Average (LWMA) Proof of Stake in 2024 marked a crucial advancement:

{% @mermaid/diagram content="graph LR
A\[HPoW] -->|95% Power Reduction| B\[LWMA PoS]
B --> C\[Enhanced Security]
B --> D\[Improved Efficiency]
B --> E\[Environmental Sustainability]
B --> F\[Community Governance]" %}

#### Storage Architecture Evolution

{% @mermaid/diagram content="graph TD
A\[Initial Blockchain] -->|2019| B\[API-Based Storage]
B -->|2024| C\[Native RPC Storage]
C --> D\[Message Queuing]
C --> E\[File Sharding]
C --> F\[Authentication]
C --> G\[Authorization]" %}

### Current Technical Architecture

#### Core Components

1. **Blockchain Foundation**
   * Built on Bitcoin Core v25
   * LWMA Proof of Stake consensus
   * Native storage capabilities
   * Integrated security protocols
2. **Storage Implementation**
   * Direct on-chain storage
   * No Layer 2 dependencies
   * Native file sharding
   * Integrated authentication
3. **Network Specifications**
   * 500GB annual storage capacity per implementation
   * Exponential scaling through cloning
   * Optimized block parameters
   * Enhanced transaction efficiency

#### Technical Advantages

{% @mermaid/diagram content="mindmap
root((Lynx Platform))
Storage
Native Implementation
No Layer 2
Direct Blockchain
File Sharding
Security
Integrated Auth
PoS Consensus
Immutable Records
Cryptographic Verification
Scalability
Implementation Cloning
Storage Expansion
Performance Optimization
Network Growth
Sustainability
Energy Efficient
Resource Optimized
Long-term Viable
Environmentally Conscious" %}

### Storage Capabilities

#### Data Management Architecture

Lynx's unique approach to data storage incorporates several innovative features:

1. **Direct Blockchain Storage**
   * Complete file encoding on-chain
   * No external dependencies
   * Permanent accessibility
   * Immutable record keeping
   * Asset UUID obfuscation
2. **Advanced Features**
   * Message queuing system
   * Digital asset sharding
   * Native authentication
   * Integrated authorization
   * On-chain asset encryption

#### Storage Flow

{% @mermaid/diagram content="graph TB
A\[File Upload] --> B\[Native Processing]
B --> C\[Sharding]
C --> D\[Blockchain Storage]
D --> E\[Permanent Access]
B --> F\[Authentication]
F --> D" %}

### Implementation Benefits

#### Technical Advantages

* Simplified architecture without Layer 2 complexity
* Direct blockchain verification
* Reduced failure points
* Enhanced security through native integration
* Improved cross-component performance

#### Practical Applications

* NFT asset storage
* Academic research preservation
* Media content archiving
* Document permanence
* Historical record keeping

### Future Capabilities

The current architecture provides a foundation for:

* Enhanced storage optimization
* Advanced sharding mechanisms
* Improved scaling capabilities
* Extended functionality without additional layers
* Increased network efficiency

### Technical Specifications

#### Current Parameters

* Annual Storage: 500GB per implementation
* Consensus: LWMA Proof of Stake
* Base: Bitcoin Core v25
* Authentication: Native on-chain
* Storage: Direct blockchain encoding

#### Performance Metrics

* Significantly reduced power consumption
* Optimized transaction processing
* Enhanced network validation
* Improved storage efficiency
* Sustainable scaling capabilities

### Conclusion

Lynx's evolution from a traditional cryptocurrency to an advanced blockchain storage platform demonstrates the potential for blockchain technology beyond financial transactions. The platform's integrated approach to data storage, combined with its efficient consensus mechanism and scalable architecture, positions it as a leading solution for permanent digital preservation.

***

*This technical overview represents the current state of Lynx architecture and capabilities as of 2024. Future updates and improvements will continue to enhance the platform's functionality while maintaining its core principles of simplicity, efficiency, and reliability.*


# Contact Us

The Lynx Development team is interested to hear from you.

{% embed url="<https://o1de3epyuzv.typeform.com/to/m04KvmJl>" %}


# Evolution of a Blockchain

Published: October 2024 | Last updated: January 2026

### Origins and Evolution

Lynx represents the evolution of blockchain technology from its early cryptocurrency roots to a sophisticated data storage platform. The project's origins trace back to Kittehcoin (MEOW), a 2013 blockchain initiative that emerged during the early expansion of alternative cryptocurrencies, following the success of Dogecoin.

[*Lynx maintains the original chain from its Kittehcoin roots*](https://chainz.cryptoid.info/lynx/block.dws?e7dd146b0867a671abf67d7292e2f62b1ae8854f58ca367547297f0b7f115498.htm)*. Kittehcoin = Lynx*

### Historical Foundation

Kittehcoin initially garnered significant community support, launching successfully in the wake of Dogecoin's popularity. However, the platform faced technical challenges that would ultimately necessitate its transformation. A critical vulnerability in the original codebase allowed malicious actors to exploit block rewards, creating uncontrolled inflation in the coin supply. This security breach fundamentally compromised the platform's economic model and led to a period of decline.

### Technical Renaissance

In 2017, the project entered a new phase under the leadership of Benjamin Wilson, a technical application designer with over 25 years of software development experience. Wilson's approach to blockchain development focused on solving concrete technological challenges rather than creating speculative new tokens. This philosophy led to a comprehensive technical overhaul of the platform.

#### Strategic Development Decisions

The decision to evolve an existing blockchain platform, rather than launch a new one, was based on several strategic factors:

1. Established Community: An existing ecosystem of users and stakeholders provided a foundation for growth
2. Economic Alignment: Community members held a vested interest in the platform's success
3. Problem-Solving Focus: The project addressed specific technical challenges rather than speculative market opportunities
4. Technical Credibility: Demonstrated ability to solve complex blockchain engineering problems

### Technical Implementation

The transformation to Lynx involved sophisticated blockchain engineering:

* Complete migration to a Litecoin-based codebase
* Preservation of the original Kittehcoin transaction history
* Integration of enhanced security protocols
* Implementation of sustainable economic models

This technical evolution maintained blockchain continuity while significantly enhancing the platform's capabilities and security.

### Modern Implementation

Today, Lynx stands as a robust blockchain platform that combines:

* Advanced data storage capabilities
* Proven security architecture
* Scalable implementation model
* Sustainable economic framework

The platform's evolution from a traditional cryptocurrency to a comprehensive blockchain storage solution demonstrates the potential for technical innovation in addressing real-world data preservation challenges.

***

Through this transformation, Lynx has emerged as a leading platform for blockchain-based data storage, built on a foundation of technical excellence and practical problem-solving. The project's history of overcoming technical challenges and implementing innovative solutions positions it uniquely in the blockchain ecosystem.


# Hybrid Proof of Work (HPoW) Protocol

Lynx has become a cryptocurrency that embraces Solo mining.

{% hint style="warning" %}
This historical document describes Lynx technology, discontinued in late 2024.
{% endhint %}

### System Overview

The Lynx cryptocurrency system represented an innovative approach to distributed mining operations, specifically engineered to enable individual participation through accessible hardware platforms. The system architecture prioritized solo mining operations while maintaining network security and environmental sustainability.

### Mining Architecture

#### Hardware Compatibility

The Lynx mining system operated on standard consumer hardware platforms, including:

* Raspberry Pi devices
* Standard laptop computers
* Virtual Private Servers (VPS)

The system deliberately excluded specialized mining hardware such as ASICs (Application-Specific Integrated Circuits) and GPUs (Graphics Processing Units) through architectural design constraints.

#### Built-in Mining Solution

The Lynx ecosystem incorporated a native mining implementation, eliminating dependencies on:

* External mining software
* Mining pool integration
* Specialized mining configurations

<figure><img src="/files/GjPzhOYgbwOu2lFwAjrj" alt=""><figcaption><p>The distribution of mining power worked incredibly well.</p></figcaption></figure>

### Hybrid Proof of Work (HPoW) Protocol

#### Protocol Definition

The Hybrid Proof of Work protocol implemented a sophisticated consensus mechanism designed to maintain network decentralization and ensure fair distribution of mining rewards.

#### Core Protocol Parameters

The protocol enforced three fundamental operational constraints:

Block Succession Control: Individual miners were prevented from securing consecutive blocks within a 60-block window, ensuring distributed participation across the network.

Dynamic Balance Requirements: Miners were required to maintain a minimum balance threshold in their reward addresses. This threshold fluctuated based on network conditions, serving as a stake-based validation mechanism.

Randomized Selection Process: The protocol implemented a random selection algorithm that prevented high-performance systems from dominating block rewards, ensuring equitable distribution regardless of hardware capabilities.

### Power Optimization

#### Energy Efficiency

The Lynx network architecture incorporated advanced power optimization techniques, resulting in significantly reduced energy consumption compared to traditional proof-of-work cryptocurrencies such as Bitcoin.

#### Environmental Impact

The system's power optimization features worked in conjunction with the HPoW protocol to maintain a sustainable network infrastructure while preserving core cryptocurrency functionality and security requirements.

### Technical Specifications

* Mining Algorithm: Hybrid Proof of Work (HPoW)
* Block Interval Protection: 60 blocks
* Hardware Requirements: Standard computing devices
* External Dependencies: None (self-contained mining implementation)
* Power Consumption: Optimized for minimal environmental impact


# Pioneering Blockchain Data Storage

Published: October 2024 | Last updated: November 2024

### Strategic Evolution

The year 2019 marked a transformative moment in Lynx's development as the platform expanded beyond traditional blockchain transactions into comprehensive data storage solutions. This strategic evolution recognized blockchain technology's untapped potential for preserving digital content beyond financial records, leading to the development of sophisticated storage capabilities.

### Technical Innovation

The implementation of a specialized API framework transformed Lynx into a versatile data storage platform, specifically engineered to meet the demands of research institutions and enterprise clients. This technical advancement enabled the platform to accommodate an extensive range of digital assets, from academic research and medical records to multimedia content and NFT assets, all while maintaining the inherent security and immutability of blockchain technology.

### Enterprise Implementation

As the platform matured, numerous organizations, particularly within the NFT ecosystem, adopted Lynx as their primary storage solution. The platform's ability to maintain persistent accessibility to digital assets proved especially valuable for NFT projects, where long-term data preservation is crucial. Unlike conventional storage solutions that often face accessibility challenges over time, Lynx's blockchain architecture ensures that stored assets remain permanently accessible and verifiable.

Through this evolution, Lynx has established itself as a pioneering force in blockchain-based data storage, demonstrating that distributed ledger technology can effectively serve as a foundation for permanent, secure digital asset preservation. This transformation from a traditional blockchain to a comprehensive data storage platform represents a significant advancement in the practical application of blockchain technology.


# Evolution to Proof of Stake

Published: August 2024 | Last updated: January 2026

### Technical Transformation

In 2024, Lynx implemented a fundamental architectural change by transitioning from Hybrid Proof of Work (HPoW) to a Linear Weight Moving Average (LWMA) Proof of Stake consensus mechanism. This migration, starting from Bitcoin Core v25, represents a significant technical advancement that dramatically improved the platform's efficiency and environmental impact.

### Technical Implementation

#### Core Architecture

The new Proof of Stake implementation incorporates several key innovations:

* Integration starting from the Bitcoin Core v25 codebase
* Implementation of LWMA consensus mechanism
* Enhanced network validation protocols
* Expanded security features from Bitcoin's latest release

#### Environmental Impact

The transition achieved measurable improvements in network efficiency:

* 95% reduction in global power consumption
* Significantly reduced carbon footprint
* Improved energy efficiency per transaction
* Sustainable scaling capabilities

#### Technical Advantages

The adoption of LWMA Proof of Stake provides several critical benefits:

* Enhanced network security through stake-based validation
* Improved transaction processing efficiency
* Reduced network congestion
* More predictable block generation

### Platform Maturation

The migration from Litecoin-based code to Bitcoin Core v25 represents a strategic technical evolution. This upgrade provides:

* Advanced security protocols
* Improved performance metrics
* Enhanced scalability features
* Current cryptographic implementations

### Governance and Participation

The LWMA Proof of Stake mechanism introduces a more inclusive validation model:

* Stakeholder participation in network validation
* Planned decentralized governance structure
* Community-driven network security
* Proportional representation in consensus

### Environmental Leadership

This technical evolution positions Lynx as a leader in sustainable blockchain technology:

* Minimal energy requirements for network operation
* Efficient resource utilization
* Scalable without proportional energy increase
* Environmentally conscious growth model

### Future Implications

The implementation of LWMA Proof of Stake creates a foundation for future development:

* Sustainable network growth
* Enhanced security features
* Improved transaction throughput
* Advanced staking mechanisms

***

This architectural transformation demonstrates Lynx's commitment to technical excellence and environmental responsibility, establishing new standards for sustainable blockchain operations while maintaining robust security and performance metrics.


# Next Generation Data Storage Architecture

Published: October 2024 | Last updated: November 2024

### Technical Evolution

In 2024, Lynx implemented a fundamental architectural transformation of its data storage capabilities, transitioning from the original API-based system to an advanced RPC (Remote Procedure Call) solution. This evolution represented a significant advancement in blockchain-based data storage efficiency and security.

### Architectural Improvements

The new architecture introduces sophisticated on-chain features that substantially enhance the platform's storage capabilities. Unlike many blockchain platforms that rely on Layer 2 solutions for advanced functionality, Lynx implements all operations—including message queuing, digital asset file sharding, authentication, and authorization—directly on the blockchain. This integrated approach eliminates the complexity and potential vulnerabilities of additional layers while maintaining superior performance. The platform achieves improved data management while maintaining backward compatibility with existing stored content. This architectural refinement resulted in a fivefold increase in storage capacity without compromising data integrity or accessibility.

#### Native Integration

Lynx's distinctive approach to blockchain architecture ensures that all operations occur directly on-chain, without reliance on external layers or secondary protocols. This design choice provides several advantages:

* Simplified system architecture without Layer 2 complexity
* Direct blockchain verification of all operations
* Reduced potential points of failure
* Improved security through native integration
* Enhanced performance through elimination of cross-layer communication

### Core Optimization

Fundamental blockchain parameters, including block time and size specifications, underwent careful optimization to support generational data storage requirements. These modifications enable more efficient data storage methodologies while ensuring long-term sustainability. The enhanced architecture maintains complete compatibility with previously stored data while implementing more efficient storage protocols for new content.

### Technical Advantages

The transition to RPC-based architecture delivers several critical improvements over the previous API implementation:

* Enhanced security through integrated authentication protocols
* Optimized data distribution through intelligent sharding
* Improved transaction efficiency through message queuing
* Expanded storage capacity with maintained performance
* Streamlined integration capabilities for enterprise applications

This architectural evolution demonstrates Lynx's commitment to continuous technical advancement while maintaining the platform's core principles of data permanence and accessibility. The new implementation sets a foundation for future scalability while preserving the integrity of historically stored data.


# Preserving Knowledge

Published: October 2024 | Last updated: January 2026

### The Revolutionary Impact of Blockchain Data Storage

In an era where digital information faces constant threats of loss, manipulation, or obsolescence, Lynx blockchain technology offers a groundbreaking solution for permanent data storage. With the capability to store theoretically unlimited data through its ever expanding infrastructure, Lynx presents unprecedented opportunities for preserving humanity's intellectual and cultural heritage. This article explores the transformative benefits of Lynx's permanent blockchain storage for books, news articles, scientific research, and academic works—ensuring that critical knowledge remains accessible, immutable, and verifiable for future generations.

### The Lynx Advantage

The Lynx blockchain platform stands out in the blockchain ecosystem through its innovative approach to data storage. With its recent expansion to 200TB of annual storage capacity—a 400-fold increase from its original 500GB—and the technical capability to scale further without architectural limitations, Lynx creates a truly scalable and sustainable solution for permanent data preservation. This expandable architecture ensures that as storage needs grow and more organizations adopt the Lynx framework, the platform can continue scaling to meet increasing demands for immutable, permanent data storage.

### Preserving Literary Heritage

#### Books and Cultural Documents

Traditional digital storage of books faces numerous challenges, from format obsolescence to server failures and capacity limitations. Lynx's blockchain storage offers an immutable, distributed solution that ensures books remain accessible for future generations. Once data is committed to the Lynx blockchain, it cannot be removed, edited, or altered by any entity—including governments, corporations, or political actors seeking to revise or erase historical records. This is particularly crucial for:

* Rare and out-of-print books that risk being lost to time
* Cultural texts from marginalized communities
* Historical documents that require preservation
* Independent publications that lack institutional backing
* Controversial or politically sensitive works that may face censorship pressures

The permanent and immutable nature of Lynx's storage means that once a book is stored, it becomes part of an unchangeable record, protected from censorship, revisionist editing, accidental deletion, or technological obsolescence. Unlike traditional archives that may require subscriptions, institutional access, or special permissions, content stored on Lynx can be accessed at any time in the future, without fees or barriers, simply by sharing the unique URL. This creates a trustless preservation system where the integrity of stored content is mathematically guaranteed rather than dependent on the goodwill of any central authority, and where access remains perpetually open to anyone with the link.

### Safeguarding Journalistic Integrity

#### News Articles and Media Content

In an age of disinformation and digital manipulation, Lynx provides crucial benefits for journalism:

1. **Immutable Record Keeping**: Once published on Lynx, news articles cannot be altered or deleted, creating a permanent historical record
2. **Version Control**: Any updates or corrections can be tracked while maintaining the original content
3. **Protection Against Censorship**: Lynx's distributed storage ensures that important news stories remain accessible even under political pressure
4. **Historical Preservation**: Future historians can access primary sources without concerns about digital decay or lost archives

### Advancing Scientific Progress

#### Scientific Research Preservation

The scientific community faces significant challenges in maintaining research data and ensuring reproducibility. Lynx offers solutions that could revolutionize scientific archiving:

**Benefits for Scientific Research:**

* **Data Integrity**: Research data stored on Lynx cannot be tampered with, ensuring the validity of findings
* **Reproducibility**: Complete datasets remain accessible for verification and further study
* **Attribution**: Clear records of research ownership and chronology
* **Accessibility**: Global access to research data without institutional barriers
* **Long-term Preservation**: Protection against data loss due to institutional changes or funding cuts

### Elevating Academic Achievement

#### Theses and Dissertations

Academic works represent the pinnacle of scholarly achievement, yet many remain difficult to access or risk being lost over time. Lynx's permanent storage provides:

1. **Universal Access**: Breaking down paywalls and institutional barriers
2. **Permanent Preservation**: Protecting academic achievements for future generations
3. **Verifiable Attribution**: Clear proof of authorship and timestamp of publication
4. **Cross-referencing Capabilities**: Easy linking between related works
5. **Global Collaboration**: Facilitated sharing of knowledge across institutions and borders

### Technical Advantages of Lynx

#### Scalability and Accessibility

With 200TB of annual storage capacity in the current implementation—and the technical capability to scale further without architectural limitations—Lynx offers substantial space for academic and literary content. The expandable infrastructure provides unlimited growth potential, ensuring:

* Sufficient capacity for large-scale archiving projects of any size
* Multiple redundant copies across different implementations
* Distributed global access points
* Scalable storage solutions that grow seamlessly with content needs
* Enterprise-grade capacity for institutional archives and digital libraries

The absence of hard storage limits means that preservation projects are constrained only by implementation choices rather than technological barriers, allowing Lynx to accommodate everything from individual book collections to comprehensive national archives.

#### Data Integrity and Security

Lynx's blockchain technology provides inherent security features that make it ideal for preserving important documents:

* Cryptographic verification of content authenticity
* Distributed storage preventing single points of failure
* Immutable record-keeping
* Transparent access logs and usage tracking

### Preserving Digital Media and Personal Heritage

#### Musical Legacy

Lynx's blockchain offers a unique solution for preserving musical heritage:

* **Digital Music Archives**: Permanent storage of digital music files
* **Historical Recordings**: Preservation of rare and historical performances
* **Independent Artists**: Platform for storing original compositions
* **Music Documentation**: Storage of sheet music, lyrics, and musical documentation
* **Cultural Music Heritage**: Preservation of traditional and indigenous music

#### Visual Culture and Memes

Modern digital culture, including memes and viral content, represents a significant aspect of contemporary history:

* **Meme Archives**: Preserving internet culture and digital phenomena
* **Evolution Tracking**: Recording how memes change and spread over time
* **Cultural Context**: Maintaining the historical context of digital trends
* **Creator Attribution**: Protecting original creators' rights and history
* **Digital Anthropology**: Supporting research into internet culture

#### Personal Media Preservation

**Voice Messages and Audio Memories**

Lynx provides a permanent solution for preserving precious audio memories:

* **Voicemail Archives**: Store important voice messages from loved ones
* **Family Recordings**: Preserve family stories and oral histories
* **Personal Audio Journals**: Maintain audio diaries and personal recordings
* **Legacy Messages**: Store messages for future generations
* **Memorial Collections**: Create lasting audio memorials of departed family members

**Family Photography**

Protecting family visual history through permanent storage:

* **Photo Collections**: Preserve family photographs permanently
* **Digital Albums**: Organize and maintain family photo collections
* **Historical Documentation**: Store genealogical visual records
* **Restoration Projects**: Archive restored historical family photos
* **Event Documentation**: Preserve important family events and celebrations

**Film and Video**

Lynx's storage capacity makes it ideal for preserving video content:

* **Home Movies**: Store family videos and home recordings
* **Documentary Content**: Preserve personal documentary projects
* **Event Recordings**: Archive recordings of significant events
* **Video Messages**: Store video time capsules for future generations
* **Historical Footage**: Preserve important historical video content

#### Digital Time Capsules

Lynx enables the creation of comprehensive digital time capsules:

* **Mixed Media Collections**: Combine photos, videos, and audio in one secure location
* **Family Archives**: Create permanent family historical records
* **Personal Legacy**: Build digital legacies for future generations
* **Memory Preservation**: Store important personal and family memories
* **Cultural Heritage**: Preserve personal contributions to cultural history

### Societal Impact Through Lynx

#### Democratizing Knowledge

Lynx's permanent blockchain storage democratizes access to information in unprecedented ways:

1. **Equal Access**: Anyone with internet connectivity can access stored content
2. **Preservation of Minority Voices**: Equal opportunity for preserving diverse perspectives
3. **Resistance to Censorship**: Protection against political or institutional control
4. **Global Reach**: Breaking down geographical and institutional barriers

#### Future Benefits

The long-term implications of Lynx's permanent storage include:

* **Historical Record**: Creating an unalterable record of human knowledge
* **Research Efficiency**: Faster access to historical data and research
* **Cultural Preservation**: Protection of cultural heritage for future generations
* **Educational Access**: Improved availability of educational resources

### Conclusion

The implementation of Lynx's permanent blockchain storage represents a paradigm shift in how we preserve and share human knowledge. With 200TB of annual storage capacity in the current implementation—and the technical capability to scale further without architectural limitations—Lynx offers a robust solution to the challenges of digital preservation. The expandable infrastructure ensures that this system can grow to meet future needs while maintaining the integrity and accessibility of stored content, all without fees or barriers to access for anyone with the unique URL.

For books, news articles, scientific research, and academic works, Lynx provides not just storage, but true preservation—ensuring that our intellectual heritage remains intact, unalterable by any political or corporate entity, and perpetually accessible for future generations. As we continue to generate more digital content in an era of increasing censorship pressures and centralized control, the value of permanent, immutable, and openly accessible storage becomes increasingly critical, making Lynx's blockchain storage an essential tool for preserving human knowledge and cultural heritage in a trustless, mathematically guaranteed system.

***

*This document explores just a fraction of the potential applications and benefits of Lynx's permanent blockchain storage. As the technology continues to evolve and storage capacity continues to expand, we can expect even more innovative uses and advantages to emerge.*


# Lynx Introduces Blockchain Recycling Initiative

Published: January 2026 | Last updated: January 2026

### **Lynx Introduces Blockchain Recycling Initiative to Transform Dead Coins into Data Storage Utility**

Industry-First Strategy Repurposes Abandoned Cryptocurrency Projects While Preserving Token Holder Value

Lynx, a blockchain-based data storage platform, has announced an ambitious expansion strategy that goes beyond creating new blockchains to include the rehabilitation of abandoned and defunct cryptocurrency projects. The initiative transforms worthless tokens from failed or neglected projects into functional utility tokens within Lynx's distributed storage infrastructure, while maintaining the complete historical transaction record of the original chains.

### The Problem of Abandoned Blockchain Projects

The cryptocurrency landscape has become increasingly cluttered with thousands of abandoned projects, many of which launched during various market cycles only to be left without developer support, used for pump-and-dump schemes, or simply faded into irrelevance. These "dead coins" typically leave token holders with worthless assets and contribute to the perception of cryptocurrency as a wasteland of failed experiments. Lynx's approach offers an alternative to this outcome by giving these projects a second life with genuine utility.

### The Recycling Process

Under the recycling program, Lynx identifies blockchain projects that have lost active development, community support, or meaningful trading volume. The company then initiates conversations with existing project maintainers when available, proposing to hard fork the chain and integrate it into Lynx's storage network. In cases where projects are truly abandoned with no responsive development team, Lynx proceeds with the hard fork independently, allowing the market and node operators to decide which chain tip to follow.

### Technical Implementation and UTXO Preservation

The technical implementation preserves the complete UTXO history of the adopted blockchain, ensuring that all existing token holders retain their balances and transaction records. The hard fork transitions the chain from its original consensus mechanism to Lynx's Proof of Stake system while adding the blockchain-based data storage capabilities that form the core of Lynx's technology. Original project names and ticker symbols are maintained, though the codebase is rebranded to identify the chain as a participant in the Lynx infrastructure.

### Governance and Development Control

From a governance perspective, Lynx assumes full control of the code repository and ongoing development. Original development teams, where they exist and choose to remain involved, benefit from professional code maintenance and active project management, though they do not share in the data storage revenue generated by the repurposed chain. This model allows former project leaders to see their work continue with real-world utility while freeing them from the burden of ongoing maintenance.

### Integration with Existing Infrastructure

The initiative runs parallel to Lynx's existing strategy of launching new blockchain instances specifically designed for data storage. The company has already deployed over four hundred chains as part of its distributed storage architecture, recently expanding total network capacity from 500 gigabytes to 200 terabytes annually. The addition of recycled chains accelerates this expansion without the bootstrapping costs and time investment required to establish entirely new projects from scratch.

### Value Recovery for Token Holders

For token holders of defunct projects, the transformation represents an unexpected recovery of value. Coins that may have been written off as complete losses gain utility within a functioning storage network, creating a tangible use case that didn't exist under the original project. While the market will ultimately determine the value of these repurposed tokens, the shift from zero utility to genuine function represents a significant change in the fundamental value proposition.

### Environmental Impact and Energy Efficiency

The blockchain recycling initiative delivers substantial environmental benefits by eliminating energy-intensive Proof of Work mining from adopted chains. Many legacy cryptocurrency projects consume significant electrical power through mining operations, even those with minimal transaction activity or market value. By transitioning these chains to Lynx's Proof of Stake consensus mechanism, the energy requirements drop by more than ninety-nine percent compared to continued Proof of Work operation.

This energy reduction becomes particularly meaningful when applied across dozens or hundreds of adopted chains. While individual abandoned projects may have relatively small mining networks, the aggregate energy consumption across the entire landscape of struggling or defunct Proof of Work coins represents a measurable environmental cost with no corresponding economic or social benefit. Converting these chains to Proof of Stake eliminates this waste while simultaneously creating genuine utility through data storage functionality.

The environmental case extends beyond the direct energy savings from consensus mechanism changes. By repurposing existing blockchain infrastructure rather than exclusively launching new chains, Lynx reduces the carbon footprint associated with bootstrapping fresh projects and building new communities from scratch. The recycling approach leverages existing token distribution, established network effects, and pre-existing infrastructure, avoiding the duplicative resource consumption that occurs when yet another new cryptocurrency project enters an already crowded market.

For legacy chains already operating on Proof of Stake consensus mechanisms, the upgrade to Lynx's proven algorithm may not deliver the same dramatic energy reductions but still contributes to ecosystem efficiency by consolidating these isolated projects under active maintenance. This prevents the gradual decay and eventual abandonment that leads to wasted development effort and stranded digital assets, creating a more sustainable model for blockchain project lifecycles.

### Ecosystem Benefits and Industry Impact

The environmental and ecosystem benefits extend beyond individual token holders. By repurposing existing blockchain infrastructure rather than contributing additional new chains to an already crowded market, Lynx addresses the accumulation of abandoned projects that create confusion for newcomers and dilute the credibility of the broader cryptocurrency industry. The initiative also demonstrates a practical approach to chain proliferation, where multiple blockchains serve a coordinated purpose rather than existing as isolated, competing projects.

### Project Selection and Pipeline

Lynx has indicated that project selection will be flexible and conversation-driven rather than based on strict criteria such as market capitalization or holder distribution. The company plans to maintain an active pipeline of discussions with projects at various stages of decline or abandonment, evaluating each opportunity based on technical compatibility and community receptiveness to the transition.

### Strategic Vision

The dual strategy of creating purpose-built storage chains while simultaneously adopting existing projects positions Lynx to scale its storage capacity rapidly while addressing a persistent problem in the cryptocurrency ecosystem. As blockchain technology matures beyond its speculative phase toward utility-focused applications, initiatives that extract value from past failures while building toward practical use cases may represent an important evolution in how the industry approaches both innovation and legacy management.


# Blockchain Recycling Architecture

Published: January 2026 | Last updated: January 2026

## Technical Implementation of Legacy Chain Integration

**UTXO Preservation and Consensus Migration in Distributed Storage Infrastructure**

The Lynx data storage network employs a dual-chain provisioning strategy combining purpose-built blockchain instantiation with the technical rehabilitation of legacy cryptocurrency projects. This document details the architectural approach, fork mechanics, and integration methodology for converting abandoned UTXO-based blockchains into functional storage utility chains within the Lynx distributed infrastructure.

### Overview of the Legacy Chain Problem

The cryptocurrency ecosystem contains thousands of unmaintained blockchain projects resulting from developer abandonment, failed economic models, malicious deployment, or simple obsolescence. These chains represent existing distributed ledger infrastructure with established UTXO sets, peer-to-peer networks, and historical consensus state. Rather than allowing these resources to persist as non-functional artifacts, Lynx has developed a technical framework for migrating legacy chains to the Proof of Stake consensus mechanism and blockchain-based storage capabilities that define the Lynx architecture.

### Candidate Chain Identification and Selection

The integration process begins with identification of candidate chains based on technical compatibility rather than market metrics. Suitable targets include any UTXO-based blockchain regardless of current network hashrate, node count, or trading volume. The primary technical requirement is a codebase that can accommodate the consensus transition to Lynx's proven Proof of Stake algorithm while maintaining state continuity, whether migrating from Proof of Work or upgrading from legacy Proof of Stake implementations.

### Hard Fork Implementation and State Preservation

Chain adoption proceeds through hard fork implementation that preserves the complete transaction history and UTXO set at the fork height. The fork introduces Lynx's Proof of Stake consensus rules, eliminating mining in favor of staking-based block production. Simultaneously, the fork integrates Lynx's OP\_RETURN-based data storage mechanism, which embeds arbitrary data payloads within blockchain transactions. This dual modification transforms the legacy chain from a purely transactional ledger into a distributed storage medium while maintaining backward compatibility with all pre-fork state.

### Node Operator Migration Strategy

From a node operator perspective, the hard fork presents a choice between continuing to run the legacy chain implementation or upgrading to the Lynx-maintained fork. In scenarios where active development teams remain engaged with the legacy project, the fork proceeds collaboratively with coordination on upgrade timing and communication to node operators and exchanges. For truly abandoned projects with no responsive maintainers, Lynx deploys the fork unilaterally and relies on market mechanisms and node operator incentives to drive adoption of the storage-enabled chain tip.

### Consensus Economics and Staking Incentives

The consensus migration eliminates the energy expenditure and hardware requirements associated with Proof of Work mining while introducing staking economics that align node operator incentives with network stability. Legacy coin holders automatically possess staking-capable tokens on the forked chain proportional to their pre-fork balances. These tokens function as both transactional currency within the chain's economy and as staking collateral for block production rights. The introduction of storage utility creates fee-generating activity that provides ongoing economic incentive for node operation beyond pure speculation on token price appreciation.

### Repository Governance and Maintenance Model

Repository governance transfers entirely to Lynx following the fork. The GitHub repository remains under Lynx management, with all future commits, releases, and issue triage handled by Lynx developers. Original project maintainers may continue participating in development if desired, but control over merge permissions, release schedules, and architectural decisions rests with Lynx. This centralized governance model ensures consistent maintenance standards across all chains in the Lynx infrastructure, whether purpose-built or adopted from legacy projects.

### Branding Integration and Chain Identity

Branding integration maintains the original project name and ticker symbol to preserve identity continuity for existing token holders and community members. However, the codebase itself receives modification to identify the chain as a Lynx infrastructure participant. This might include updates to client software naming, network magic bytes that distinguish the forked chain from the legacy chain at the protocol level, and documentation that positions the project within the broader Lynx storage ecosystem. The branding strategy balances preservation of legacy identity with clear technical differentiation from the pre-fork implementation.

### Data Storage Functionality and API Abstraction

Data storage functionality operates identically across adopted chains and purpose-built Lynx chains. Client applications interact with any chain in the infrastructure through a standardized API that abstracts the underlying blockchain identity. Storage operations embed data in OP\_RETURN outputs within transactions, with the Proof of Stake consensus ensuring permanent inclusion in the blockchain. The distributed nature of the storage network means data redundancy and availability depend on aggregate capacity across all participating chains rather than any single chain's characteristics.

### Economic Model and Revenue Distribution

The economic model for adopted chains differs from legacy projects in that storage fees generated by data embedding transactions accrue to Lynx rather than being distributed to legacy project stakeholders. Node operators earn staking rewards denominated in the chain's native token, creating ongoing incentive for infrastructure maintenance. However, the actual USD-denominated revenue from storage customers flows to Lynx as the platform operator. This arrangement provides legacy projects with technical sustainability through active maintenance while concentrating the business model returns with the entity providing the storage service and infrastructure coordination.

The native tokens of adopted chains serve multiple critical functions within the storage infrastructure. Staking transactions require these tokens as collateral for block production rights, while data storage operations necessitate token acquisition for transaction fees that formalize the embedding of data within the blockchain. Additionally, a portion of tokens must be burned as part of each storage transaction, permanently removing them from circulation. This burn mechanism creates constant buy pressure as the Lynx infrastructure acquires tokens to facilitate ongoing storage operations for customers. Over time, this deflationary pressure systematically reduces the circulating supply of each adopted chain's tokens, potentially increasing scarcity and value for remaining token holders while ensuring continuous economic activity regardless of speculative trading patterns.

### Network Effects and Horizontal Scaling

Network effect accumulation occurs both at the individual chain level and across the aggregate infrastructure. Each adopted chain adds storage capacity measured in the annual data volume supportable given block size limits and target block times. With over four hundred chains currently deployed and an active pipeline for legacy chain adoption, the infrastructure scales horizontally by adding chains rather than vertically by increasing individual chain capacity. This architecture distributes risk across many independent consensus networks while allowing clients to treat the entire infrastructure as a unified storage platform.

### Fork Activation Mechanics and Chain Split Dynamics

Network effect accumulation occurs both at the individual chain level and across the aggregate infrastructure. Each adopted chain adds storage capacity measured in the annual data volume supportable given block size limits and target block times. With five-minute block intervals and five-megabyte block sizes, each chain provides approximately 526 gigabytes of annual storage capacity, calculated as 5 MB × 105,120 blocks per year. This yields a simple scaling formula where total infrastructure capacity equals 0.526N terabytes annually, with N representing the number of deployed chains. With over four hundred chains currently deployed and an active pipeline for legacy chain adoption, the infrastructure scales horizontally by adding chains rather than vertically by increasing individual chain capacity. At current deployment levels, the aggregate network provides over 210 terabytes of annual storage capacity, with each additional adopted chain contributing an incremental half-terabyte of capacity. This architecture distributes risk across many independent consensus networks while allowing clients to treat the entire infrastructure as a unified storage platform.

**Annual Storage Capacity = (Block Size × Blocks per Year × Number of Chains)**

Where:

* Block Size = 5 MB
* Blocks per Year = (60 minutes ÷ 5 minutes) × 24 hours × 365 days = 105,120 blocks
* Number of Chains = N

**Formula:**

```
Annual Storage (MB) = 5 MB × 105,120 × N
Annual Storage (MB) = 525,600N MB
Annual Storage (GB) = 525.6N GB
Annual Storage (TB) = 0.5256N TB
```

**Simplified:**

```
Annual Storage ≈ 0.526N TB per year
```

Or approximately **526 GB per chain per year**.

**Examples:**

* 1 chain = 526 GB/year
* 100 chains = 52.6 TB/year
* 400 chains = 210.4 TB/year
* 1,000 chains = 526 TB/year

### Technical Debt Assessment and Integration Risk

From a technical debt perspective, adopted chains carry architectural decisions and code quality characteristics from the legacy implementation. Lynx developers evaluate this inheritance during the adoption assessment process, determining whether legacy technical debt is manageable within the maintenance framework or whether certain projects present integration challenges that outweigh the benefits of adoption. Projects with particularly problematic codebases may be rejected in favor of purpose-built chain instantiation, while those with clean Bitcoin-derived implementations integrate with minimal friction.

### Parallel Expansion Strategy

The recycling initiative operates in parallel with new chain creation rather than replacing it. Purpose-built chains allow optimization for specific storage use cases, custom parameterization of block times and sizes, and implementation of experimental features without the constraint of maintaining compatibility with legacy UTXO sets. Adopted chains provide rapid capacity expansion and demonstrate practical utility recovery from failed projects, serving both technical and ecosystem-level objectives. The combination of both strategies positions the infrastructure for aggressive scaling while contributing to the cleanup of abandoned cryptocurrency projects that clutter the broader ecosystem.

### Energy Consumption and Environmental Impact

The consensus migration from Proof of Work to Proof of Stake delivers measurable reductions in energy consumption and carbon emissions. Proof of Work mining requires continuous computational effort to solve cryptographic puzzles, with electricity consumption scaling proportionally to network hashrate. Even modest Proof of Work chains with limited mining participation consume kilowatts of continuous power, while larger networks require megawatts or even gigawatts. This energy expenditure persists regardless of transaction volume or network utility, creating ongoing environmental cost even for chains with minimal economic activity.

Lynx's Proof of Stake implementation eliminates mining hardware requirements entirely. Block production occurs through staking mechanisms where nodes lock collateral rather than performing computational work. The energy requirements for Proof of Stake validation approximate those of running standard server infrastructure, typically measured in watts rather than kilowatts per node. Empirical measurements of Proof of Stake networks demonstrate energy consumption reductions exceeding ninety-nine percent compared to equivalent Proof of Work implementations, with some analyses suggesting reductions of 99.95 percent or higher depending on the specific protocols compared.

For legacy chains operating Proof of Work consensus at the time of adoption, the hard fork to Lynx's Proof of Stake represents an immediate cessation of mining energy consumption. Miners either shut down their hardware or redirect it to other Proof of Work chains, while the forked chain continues operation using only the minimal energy required for staking nodes. The environmental benefit scales with the hashrate of the adopted chain at fork time, though even low-hashrate abandoned projects contribute meaningful aggregate savings when dozens or hundreds of chains undergo this transition.

Chains already operating on Proof of Stake consensus mechanisms experience less dramatic energy reductions through Lynx adoption, though optimization opportunities may still exist depending on the efficiency of their legacy staking implementation. More significantly, the integration of these chains into active infrastructure prevents their gradual abandonment and the eventual waste of all development effort and community building invested in the project. This sustainability benefit operates at the ecosystem level rather than through direct energy metrics, reducing the churn and redundancy that characterizes much of the cryptocurrency landscape.

The distributed storage use case introduces minimal additional energy overhead compared to transactional-only blockchain operation. Data embedding through OP\_RETURN outputs requires no additional consensus work beyond standard transaction validation. Storage clients must transmit data to nodes for inclusion in blocks, but this network bandwidth consumption approximates that of any cloud storage service. The blockchain consensus mechanism ensures data persistence and availability, but the incremental energy cost of storing data versus processing empty blocks remains negligible in Proof of Stake implementations.

Lifecycle analysis comparing blockchain recycling to new chain creation reveals additional environmental advantages. Launching a new cryptocurrency project requires community building, exchange listings, wallet development, block explorer deployment, and ecosystem tooling creation. While these activities primarily consume human effort rather than direct energy, they represent resource allocation that could serve other purposes. Repurposing existing chains with established infrastructure, existing community members, and pre-deployed tooling reduces this duplicative effort, creating a more efficient path to capacity expansion.

The environmental narrative around blockchain technology has historically focused on Bitcoin's energy consumption and the broader Proof of Work mining ecosystem. By actively reducing the number of Proof of Work chains in operation and demonstrating practical migration paths to energy-efficient consensus mechanisms, Lynx contributes to shifting the industry toward more sustainable technical foundations. Each adopted chain represents not only direct energy savings but also a proof point that blockchain utility can decouple from energy-intensive mining operations.

Quantifying the aggregate environmental impact requires estimating the hashrate distribution across potential adoption candidates and projecting the rate of chain integration. Conservative assumptions suggest that adopting even a few dozen Proof of Work chains with modest hashrates could eliminate megawatt-hours of annual energy consumption. More aggressive expansion targeting hundreds of legacy chains could drive energy reductions measured in gigawatt-hours annually, equivalent to the power consumption of thousands of households. These projections depend on actual adoption rates and the specific characteristics of integrated chains, but the directional impact remains clearly positive.

The energy efficiency gains extend beyond environmental benefits to practical operational advantages. Proof of Stake node operation requires commodity server hardware rather than specialized mining equipment, reducing capital expenditure and hardware obsolescence concerns. Lower energy consumption translates to reduced operating costs for node operators, improving the economic sustainability of network infrastructure. These economic advantages reinforce the technical benefits of Proof of Stake adoption, creating aligned incentives for legacy chain communities to embrace the fork rather than continuing Proof of Work operation.

### Integration Testing and Quality Assurance

Integration testing for adopted chains follows the same validation procedures as new chain deployment. Test networks verify consensus correctness, storage operation functionality, and compatibility with client libraries and APIs. Performance benchmarking establishes the storage throughput and capacity characteristics of each chain. Only after completing this validation pipeline do adopted chains enter production operation within the storage infrastructure.

### Long-Term Vision and Scaling Trajectory

The long-term vision positions blockchain recycling as a standard expansion mechanism alongside purpose-built chain creation. As the cryptocurrency industry continues maturing, the accumulation of abandoned projects will likely accelerate, creating an expanding pool of adoption candidates. Simultaneously, improvements in fork tooling and standardization of the Lynx storage implementation will reduce the engineering overhead required for each adoption, allowing the pipeline to scale efficiently. The result is a distributed storage infrastructure that grows through both organic creation and strategic repurposing of existing blockchain resources.


# Hardware and System Requirements

Published: February 2025 | Last updated: January 2026

### Overview

This document outlines the minimum hardware and system requirements for running the Lynx blockchain daemon. Please ensure your system meets these specifications before proceeding with installation.

### Hardware Requirements

#### Minimum System Specifications

* Processor: 1 CPU core
* Memory: 3GB RAM
* Storage: 32GB SSD or HDD
* Network: Broadband internet connection

{% hint style="success" %}
VPS deployments can be downsized to 1GB RAM instances after the initial sync is complete. Even with staking enabled, VPS load remains under 1%. This will lower monthly VPS vendor costs significantly.
{% endhint %}

#### Storage Considerations

The specified 32GB storage requirement is the minimum needed for initial installation and basic operation. Storage requirements will increase over time as the blockchain grows. We recommend monitoring storage usage and planning for future expansion.

### Supported Operating Systems

#### AMD Architecture

* [Debian 11 (Bullseye)](https://github.com/getlynx/Lynx/releases)
* [Debian 12 (Bookworm)](https://github.com/getlynx/Lynx/releases)
* [Ubuntu 22.04 LTS (Jammy Jellyfish)](https://github.com/getlynx/Lynx/releases)

#### ARM Architecture

* [Debian 12 (Bookworm)](https://github.com/getlynx/Lynx/releases)

### Additional Recommendations

#### System Health

* Regular system updates
* Uninterruptible Power Supply (UPS) for system stability
* Regular backup of the wallet.dat file

#### Network Requirements

* Static IP address recommended
* Open and configurable firewall
* Unrestricted inbound/outbound traffic

### **Automated VPS Deployment**

For rapid deployment of Lynx nodes on VPS infrastructure, we strongly recommend using the official automated installer script [in the official Lynx repository](https://github.com/getlynx/Lynx/blob/main/contrib/installer/install.sh). This single-command deployment tool streamlines the entire setup process, automatically handling dependencies, configuration, and initial blockchain synchronization. The installer is particularly valuable for users building staking operations, whether deploying a single VPS node or scaling to a complete staking farm across multiple servers. By eliminating manual configuration steps and potential setup errors, the automated installer significantly reduces deployment time from hours to minutes, ensuring consistent and reliable node installations across your infrastructure. This approach is ideal for both newcomers seeking a simplified setup experience and experienced operators managing distributed staking operations at scale.


# Lynx Dynamics

Published: August 2024 | Last updated: January 2025

The Lynx blockchain is a permanent data storage platform. The Lynx cryptocurrency is created (by a process called *staking*) and destroyed (by a process called *burning*) to pay for the permanent storage of computer files. The computer files or digital assets (the 'payload') can be anything from a simple text password, PDF, JPG, audio files, movie files, or an encrypted compressed backup file. Lynx is designed to make stored files accessible long after the creator is gone.

Lynx is designed to outlive us.

<figure><img src="/files/knnD22W9uAjpoHAVVz8Z" alt="" width="375"><figcaption><p>Gone are the days of lost precious family photos.</p></figcaption></figure>

The Lynx blockchain shares cryptocurrency features with traditional blockchains like Bitcoin, such as the ability to send and receive and for individuals to stake (both the verification process of data storage and the creation process of new Lynx cryptocurrency). The overwhelming usage of the Lynx blockchain involves permanently storing digital assets. Lynx is not competing with Bitcoin, has little concern for the fluctuating price of Lynx, and does not try to hide transactions that occur on its blockchain from outside review. It is the transparency of the Lynx blockchain that reinforces confidence in its use. When stored, a file can be independently accessed and verified by anyone without fees or permission.

{% hint style="info" %}
In economics, a commodity is a basic good or raw material interchangeable with other goods of the same type. Commodities are usually inputs in the production of other goods or services. The primary characteristic of a commodity is its uniformity or standardization, meaning that a given quantity of the commodity is essentially identical regardless of its source. This makes commodities fungible and tradable in markets where the commodity's price is determined largely by supply and demand.
{% endhint %}

The Lynx coins are burned or destroyed when storing data. This makes the Lynx coins much like a commodity such as natural gas or crude oil. Yes, some entities buy and sell them, but Lynx cryptocurrency has a use. In the case of crude oil, after processing and transportation, it can be used to ship goods, heat homes, and build products. Lynx coins are very much the same. They are created by stakers and sold on open markets to, ultimately, the individual or company that is storing data on the Lynx blockchain. The coins are 'burned' (destroyed), like gasoline is burned in a shipping vessel, to complete the cycle of data storage. The coins are destroyed, meaning they aren't held by anyone anymore, are inaccessible, and can't be used again, much like gasoline.

{% hint style="info" %}
Lynx coins have value. Several factors contribute to price discovery, including supply and demand dynamics, market participants' expectations, and the availability of information.
{% endhint %}

The Lynx blockchain uses a creation and verification process called Proof of Stake. This is a highly efficient, low-energy usage process that creates Lynx. Anyone can stake Lynx on even the most simple computer. Unlike Bitcoin mining and gasoline creation, creating Lynx does not negatively impact the environment by creating heat, using excessive electricity, or generating an abundant amount of e-waste (junk computers).


# Open Source

Published: September 2024 | Last updated: March 2025

Lynx revolutionizes blockchain data storage through its commitment to open source development and community-driven innovation. By making the entire codebase publicly available, Lynx enables developers and projects worldwide to build upon, enhance, and validate the platform's core technology.

Environmental sustainability stands at the forefront of Lynx's design philosophy. The energy-efficient Proof of Stake consensus mechanism dramatically reduces environmental impact compared to traditional Proof of Work systems. Through open collaboration, the community continuously optimizes the platform's efficiency, implementing innovative solutions that minimize resource consumption while maximizing storage capabilities.

Security through decentralization forms the backbone of Lynx's architecture. Rather than relying on centralized servers or single points of control, data is distributed and verified across the entire network. This approach ensures exceptional resistance to censorship and tampering, while cryptographic verification protocols maintain data integrity across all nodes. The collective validation by the network creates a robust, trustworthy storage system that eliminates single points of failure.

Looking to the future, Lynx's open source foundation enables continuous evolution and improvement. As new technologies emerge and storage needs evolve, the transparent, community-driven development process ensures the platform remains at the forefront of blockchain innovation. This adaptability, combined with a commitment to sustainability and security, positions Lynx as a lasting solution for decentralized data storage.

By merging open source principles with advanced blockchain technology, Lynx delivers a secure, sustainable, and scalable platform that serves both current demands and future possibilities in the world of decentralized data storage.

Lynx has been developed and maintained by [Deliverypath](https://deliverypath.com/) under the direction of [Benjamin Wilson](https://www.linkedin.com/in/benjaminawilson/) since 2016. The development team behind Lynx consists entirely of American developers. The Lynx cryptocurrency is available for purchase and trade at [FreiXLite](https://freixlite.com/market/LYNX/LTC). Trading Lynx involves risk of loss. You should consult your financial advisor before engaging in the high risk endeavor of buying, owning and trading cryptocurrency.


# Core Parameters and Strategy

Published: September 2024 | Last updated: January 2025

On December 25, 2023, Lynx will be a +10-year-old blockchain project. The original name, mining algorithm, and project objective have changed, but the entire blockchain history from Dec 2013 remains intact.

Here are a few points about the Lynx Blockchain project.

1. While the cryptocurrency functions of Lynx remain intact, this project's primary focus is on-chain data storage. The long-term strategy priority of the Lynx project is based on blockchain data storage, not cryptocurrency development. While this project retains the functions of a cryptocurrency, it does not compete with Bitcoin.
2. The energy consumption requirements of traditional Bitcoin Proof of Work mining are shameful. [*The world is on fire*](https://www.cbsnews.com/live-updates/california-fires-winds-updates/), and Bitcoin miners are not helping. We believe any new blockchain software development must consider the environment. While Lynx's previous Proof of Work design significantly reduced energy consumption and heat output, the new Proof of Stake design is even better. We put aside the love (and ego) of our previous mining algorithm to create a better version for the environment.
3. The latest version of Lynx is based on a newer version of Bitcoin, except we swapped out the energy-wasting functions of Proof of Work and implemented a LWMA (linear weighted moving average) Proof of Stake algorithm. The new version of Lynx is very low-cost to run and leverages all the security and [latest features of Bitcoin Core](https://bitcoincore.org/en/releases/25.0/). It is extraordinarily lightweight, consumes very few resources, and occupies a small footprint on computers that can run unnoticed in the background.
4. We modified the block time, size, and other core functions to accommodate generational data storage. The new design stores data more efficiently than the old method and is backward compatible.&#x20;
5. The latest version of Lynx can run on the least expensive VPS computers available in the cloud and the least costly (current) Raspberry Pi devices. Full support for Debian Linux will remain, while official releases for MacOS and Windows will cease. Setting up a Lynx node takes minutes with almost zero configuration.
6. Full support for hardware wallets Ledger, Trezor, and Atomic Dex. Electrum and traditional exchange support will remain.

Lynx blockchain parameters are listed below.

1. The target block time for the Lynx blockchain is 5 minutes.
2. The block size is 5 megabytes.
3. The block reward maturity time is thirty blocks.
4. The block reward for miners is 1 Lynx + fees.


# Environmental Impact

Published: March 2025 | Last updated: January 2026

### The Lynx Sustainability Philosophy

Sustainability must be a key feature for a blockchain to be considered a secure platform for business in today's global marketplace. As an eco-friendly decentralized ledger technology (DLT), Lynx strives to be a leader through its implementation of Proof of Stake consensus.

Lynx is a Bitcoin fork that has replaced the energy-intensive Proof of Work (PoW) mining mechanism with an energy-efficient Proof of Stake (PoS) consensus model. This fundamental shift eliminates the need for competitive computational mining that consumes massive amounts of electricity.

<figure><img src="https://get.clevver.org/b34219dfcfa28f028c152c6f120f96a768451a28d8f26872a4104819802f1d50.png" alt="" width="375"><figcaption><p>Lynx Project logo stored on the blockchain</p></figcaption></figure>

### Proof of Work vs Proof of Stake: Environmental Impact

Traditional Proof of Work blockchains like Bitcoin require miners to solve complex mathematical puzzles using specialized hardware, consuming enormous amounts of energy—often powered by fossil fuels. This competitive mining model incentivizes the use of high-powered mining rigs and industrial-scale operations, resulting in significant environmental costs.

In contrast, Lynx's Proof of Stake mechanism validates transactions through stake ownership rather than computational power. This approach:

* Eliminates the need for energy-intensive mining hardware
* Reduces the network's global energy consumption to a fraction of PoW systems
* Removes the incentive for consolidating mining operations in regions with cheap electricity
* Makes network participation accessible through standard computing devices

The transition to Proof of Stake allows Lynx to maintain blockchain security and decentralization while consuming dramatically less energy than Proof of Work alternatives. As global energy costs rise and environmental concerns intensify, Lynx's PoS implementation provides a sustainable foundation for long-term blockchain operations—ensuring the network remains both economically viable and environmentally responsible for future generations.


# Circulating Supply Analysis

Published: September 2024 | Last updated: January 2025

The current circulating supply of Lynx requires careful analysis due to several factors affecting coin availability and movement. As of this writing, miners have earned a total of 77,872,268,736 Lynx through block rewards since the project's inception over ten years ago.

### Security Incident Impact&#x20;

Two significant wallets, containing 16,377,591,933 and 1,610,095,400 Lynx respectively, are permanently locked due to a security incident that occurred before the current team assumed control of the project. These locked funds effectively reduce the total circulating supply to 59,884,542,893 Lynx.

### Mining and Distribution&#x20;

The mining reward structure distributes 1 Lynx plus transaction fees per block. With optimal block timing, this results in approximately 280 new Lynx (plus fees) being added to the circulating supply daily.

### Lost Coins and Actual Circulation&#x20;

Given the project's decade-long history, a significant portion of Lynx coins have become inaccessible due to lost wallet credentials or abandoned holdings. Conservative estimates suggest approximately 40 billion Lynx remain actively circulating, while more aggressive analyses indicate the number could be as low as 25 billion.

### Deflationary Mechanics&#x20;

Lynx implements a deflationary model through its data storage utility. When users store data on the blockchain using applications like Clevver or other independent tools, they must burn Lynx tokens in the process. This burning mechanism has created a significant dynamic: as data storage usage increases, the daily burn rate now exceeds the daily creation of new coins through mining. This sustained pattern means the total circulating supply of Lynx will gradually decrease over time rather than inflate.


# Locked Addresses

Why were two suspicious addresses locked?

In short, because the addresses contain provably stolen coins.&#x20;

*A bit of history.* Long ago, concerning the block numbers listed below, someone attacked Kittehcoin (before the Lynx development team took over the project). The attack exploited a weakness that allowed the attacker to define the mining reward amount. At that time, the default mining reward was only 2,000 MEOW per block. However, the blocks below show the reward was changed to 2 billion each time the attack was executed. The pattern is easy to identify. The Lynx team fixed the security hole when they ported the latest Litecoin code to the (previously named) Kittehcoin chain. While the attack vector was closed, the coins still remained in circulation, increasing the circulating supply by approximately 28 billion coins.

* Block: 1327713 — Coinbase Reward: 2,000,000,000 — Address: [K7Z3uThEHim6hvQBa1kqb6jwhp9QfynbyM](https://chainz.cryptoid.info/lynx/address.dws?K7Z3uThEHim6hvQBa1kqb6jwhp9QfynbyM.htm)
* Block: 1327710 — Coinbase Reward: 2,000,000,000 — Address: [KPwNzFNnEUcKfiuW4dyVwm9sKvY9rP24Cp](https://chainz.cryptoid.info/lynx/address.dws?KPwNzFNnEUcKfiuW4dyVwm9sKvY9rP24Cp.htm)
* Block: 1327704 — Coinbase Reward: 2,000,000,000 — Address: [KDbND8WQSXDhmEhEaV62TUH5GJaYxaVXVx](https://chainz.cryptoid.info/lynx/address.dws?KDbND8WQSXDhmEhEaV62TUH5GJaYxaVXVx.htm)
* Block: 1327689 — Coinbase Reward: 2,000,000,000 — Address: [KJqhouB6FX2xnZkGqFXCR5NMdrBgYzgcyd](https://chainz.cryptoid.info/lynx/address.dws?KJqhouB6FX2xnZkGqFXCR5NMdrBgYzgcyd.htm)
* Block: 1327646 — Coinbase Reward: 2,000,000,000 — Address: [KKquAGVnSt33WpvRbYPhCcBuaqMSskkjDB](https://chainz.cryptoid.info/lynx/address.dws?KKquAGVnSt33WpvRbYPhCcBuaqMSskkjDB.htm)
* Block: 1327595 — Coinbase Reward: 2,000,000,000 — Address: [KGaQrKE4jNzS44ZAukmLCpX1jGgsNcJNqE](https://chainz.cryptoid.info/lynx/address.dws?KGaQrKE4jNzS44ZAukmLCpX1jGgsNcJNqE.htm)
* Block: 1313353 — Coinbase Reward: 2,000,000,000 — Address: [KFu5EBViCUuUQPNufc3LEQAThVBhfP2LZz](https://chainz.cryptoid.info/lynx/address.dws?KFu5EBViCUuUQPNufc3LEQAThVBhfP2LZz.htm)
* Block: 1313352 — Coinbase Reward: 2,000,000,000 — Address: [KEgVoShXe1uManCMWB7mifFyzDB6EjGibi](https://chainz.cryptoid.info/lynx/address.dws?KEgVoShXe1uManCMWB7mifFyzDB6EjGibi.htm)
* Block: 1299977 — Coinbase Reward: 2,000,000,000 — Address: [KJ2eg8U4vqHjThLx7tpW1TovgWgURYo5Mx](https://chainz.cryptoid.info/lynx/address.dws?KJ2eg8U4vqHjThLx7tpW1TovgWgURYo5Mx.htm)
* Block: 1299963 — Coinbase Reward: 2,000,000,000 — Address: [KEcJNXRM2JZKskLy7Fw3KtQqPhcczmEV3o](https://chainz.cryptoid.info/lynx/address.dws?KEcJNXRM2JZKskLy7Fw3KtQqPhcczmEV3o.htm)
* Block: 1293504 — Coinbase Reward: 2,000,000,000 — Address: [KFFjYVKCbsQhWdEDFegCjNVugp4fE3Gmpu](https://chainz.cryptoid.info/lynx/address.dws?KFFjYVKCbsQhWdEDFegCjNVugp4fE3Gmpu.htm)
* Block: 1293496 — Coinbase Reward: 2,000,000,000 — Address: [KNJpmWvoBnQ8fLkqoi8SbRBE1xBTrybZz4](https://chainz.cryptoid.info/lynx/address.dws?KNJpmWvoBnQ8fLkqoi8SbRBE1xBTrybZz4.htm)
* Block: 1286358 — Coinbase Reward: 2,000,000,000 — Address: [KATtxFYoMwdcQJVsCJVDz2VD8K2KUpwqHt](https://chainz.cryptoid.info/lynx/address.dws?KATtxFYoMwdcQJVsCJVDz2VD8K2KUpwqHt.htm)
* Block: 1256813 — Coinbase Reward: 2,000,000,000 — Address: [KJxF5BY5zenfHtWrKGEEcPggRiJZFFrbJT](https://chainz.cryptoid.info/lynx/address.dws?KJxF5BY5zenfHtWrKGEEcPggRiJZFFrbJT.htm)

The code change implemented in v0.16.3.9 includes a restriction for the [2 largest known single addresses on the Lynx blockchain:](https://chainz.cryptoid.info/lynx/#!rich)

* KJ2MGS3jq4DPkVmE1ephMCbT7ojDcDSJRG
* KSho9zUYrFdTPPxfF6ye9sLurgKygeUEzL

The attacker(s) now has two options:

Option 1: Do nothing.

* The coins in those wallets will never be spendable. All future versions of Lynx will include the lockdown code preventing the coins from being spent. The consensus of the network prevents the coins from being moved.

Option 2: Release the coins in exchange for a bounty.

* Each of the two blocked addresses may keep 100,000,000 Lynx in their original addresses *if they send the rest of the coins to this – and only this – address:* [*KQoKm4bzQvDAwiiFsPz3AE4UJHkHBvX6Bz*](https://chainz.cryptoid.info/lynx/search.dws?q=KQoKm4bzQvDAwiiFsPz3AE4UJHkHBvX6Bz)*. Once the coins are received, the blocking code will be removed in future Lynx releases,* and the 100,000,000 coins will revert to the attackers’ control.
* If the coins are ever received at that address, a small portion will be used to reimburse the few Lynx holders who experienced theft (approximately Dec 5, 2019) from an R-value Attack. Then, the remainder of the coins will be verifiably burned. A schedule will be published, and the remaining stolen coins will be burned.

Why are we burning the stolen coins?

We’re burning the stolen coins because it’s the right thing to do. We have no interest in keeping them because it will erode trust in the Lynx project, which we take very seriously. These coins were created outside of the normal business rules of Lynx. Therefore, all Lynx holders paid for them. Lynx never had a pre-mine or ICO. The existence of the stolen coins harms every Lynx holder by suppressing the total value of the network market cap and reducing the total scarcity of the circulating supply. If these coins are burned, the total circulation should be reduced by roughly \~20%. We expect this will positively impact the entire Lynx network — *and the community of users that support it.*

{% hint style="info" %}
Our general policy is not to police the Lynx blockchain. However, we made an exception here because of the size of the theft, the number of users it impacts (everyone), and it’s easy to trace on the blockchain. We hope most of the Lynx community accepts and supports this difficult decision.
{% endhint %}


# Data Storage

Published: September 2024 | Last updated: March 2025

The following built-in RPC functions are used to interact with the data storage mechanism of Lynx Core. These functions are built into the daemon and don't require any third party software or modules. All functions listed are supported by the Enterprise version of Lynx. The Professional version of Lynx will only support the fetch() function.&#x20;

For convenience, when interacting with the Lynx daemon, the help() command will provide additional detailed documentation for each storage related function. The included documentation is respective to the version of Lynx running.

## Definitions

<details>

<summary>Tenant</summary>

A user of data storage routines. In most cases, a tenant can be thought of as a traditional user account.

</details>

<details>

<summary>Asset</summary>

A digital file. While there may be file size, type, content, and format constraints on an asset, an asset is no more and no less than a digital file.

</details>

<details>

<summary>Store</summary>

[Copy an asset](/lynx-core/data-storage/store) to the Lynx blockchain. Storage is permanent. The file can not be edited or deleted after it has been placed. If uploading encrypted assets, the tenant is responsible for the retention of decryption keys.

</details>

<details>

<summary>Fetch</summary>

[Copy an asset](#fetch) from the Lynx blockchain to the hard drive. Their is no fee to copy an asset from the blockchain. A unique identifier is required to find the requested asset.

</details>

<details>

<summary>Authorize</summary>

Make it such that a tenant, when authenticated, can perform operations allowed for that tenant.

</details>

<details>

<summary>Authenticate</summary>

Authorized tenants [authenticate](/lynx-core/data-storage/auth) by providing appropriate credentials.

</details>


# auth

Published: March 2025 | Last updated: May 2025

### Overview

The `auth` RPC method authenticates a Tenant for a time-limited session on the Lynx blockchain. This authentication process establishes the user's identity and permissions, enabling them to perform storage operations appropriate to their role. Authentication sessions have a fixed duration of approximately 6 hours (72 blocks), after which re-authentication is required.

### Syntax

```
lynx-cli auth
```

### Description

When you invoke the `auth` method with a valid private key, the Lynx daemon verifies your identity against its list of authorized users and establishes a session that grants you access to role-appropriate commands. For security purposes, the command automatically disables staking for authenticated tenants. The private key used by the auth method is stored in the lynx.conf file. Since the private key is respective to the mainnet or testnet environments, the 'rpctenent' key is prefixed with the environment name. Examples of both are below.

{% code title="\~/.lynx/lynx.conf" %}

```
# mainnet tenant key
main.rpctenant=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

# Commented testnet tenant key
# test.rpctenant=d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592
```

{% endcode %}

During authentication, the system evaluates your wallet's capacity to support storage operations, which directly determines the maximum storage capacity by the local daemon. This helps ensure that users have sufficient resources to complete their intended storage operations.

### Parameters

<table><thead><tr><th width="289.43121337890625">Parameter</th><th width="92.96246337890625">Type</th><th width="101.0843505859375">Required</th><th>Description</th></tr></thead><tbody><tr><td>[environment].rpctenant referenced from ~/.lynx/lynx.conf file </td><td>string</td><td>Yes</td><td>A valid WIF-format private key associated with an authorized tenant. This key proves your identity to the system.</td></tr></tbody></table>

### Returns

The method returns an array containing a single object with the following fields:

<table><thead><tr><th width="237">Field</th><th width="168">Type</th><th>Description</th></tr></thead><tbody><tr><td><code>result</code></td><td>string</td><td>Indicates whether authentication succeeded (<code>success</code>) or failed (<code>failure</code>).</td></tr><tr><td><code>message</code></td><td>string</td><td>Provides additional information about the result: <code>You are authenticated as a tenant</code>, <code>Invalid key</code>, <code>Unauthorized tenant</code>, or <code>No wallet</code>.</td></tr><tr><td><code>capacity</code></td><td>number</td><td>The maximum storage capacity available to the Tenant in kilobytes (KB). </td></tr><tr><td><code>sessionstart</code></td><td>string</td><td>The timestamp when the authentication session began in <code>YYYY-MM-DD HH:MM:SS</code> format.</td></tr><tr><td><code>sessionend</code></td><td>string</td><td>The timestamp when the authentication session will expire in <code>YYYY-MM-DD HH:MM:SS</code> format.</td></tr><tr><td><code>sessionstartblock</code></td><td>string/number</td><td>The blockchain height when the authentication session began.</td></tr><tr><td><code>sessionendblock</code></td><td>string/number</td><td>The blockchain height when the authentication session will expire (start block + 72). </td></tr><tr><td><code>stakingstatus</code></td><td>string</td><td>Indicates whether staking is currently <code>enabled</code> or <code>disabled</code> on the node. Always set to <code>disabled</code> for regular tenants during their session.</td></tr></tbody></table>

### Authentication Security

The authentication system implements several security measures:

* **Progressive Delay**: Failed authentication attempts introduce an exponentially increasing delay (doubling with each failure) to suppress brute force attacks.
* **Session Expiration**: Authentication sessions for regular tenants expire after approximately 6 hours (72 blocks).
* **Staking Management**: Staking is automatically disabled for regular tenants during their session to prevent resource conflicts. If staking is enabled in the lynx.conf file, staking will be enabled after the authorized tenant session expires.

### Tenant Capacity Calculation

The system calculates a tenant's storage capacity based on the number of UTXO in their wallet:

* This calculation helps tenants understand their maximum storage allocation

### Examples

#### Authenticate as a tenant

```
lynx-cli auth
```

Output for a successful tenant authentication:

```
[
  {
    "result": "success",
    "message": "You are authenticated as a tenant.",
    "capacity": 63569,
    "sessionstart": "2025-03-24 21:34:40",
    "sessionend": "2025-03-25 03:34:40",
    "sessionstartblock": 3108065,
    "sessionendblock": 3108137,
    "stakingstatus": "disabled"
  }
]
```

Using JSON-RPC:

```
curl --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "auth", "params": []}' -H 'content-type: text/plain;' http://127.0.0.1:9332/
```

### Error Handling

The method will return a failure result in the following scenarios:

* **Invalid Key**: The provided private key is empty or invalid (cannot be used to derive a valid user)
* **Unauthorized Tenant**: The key is valid but not registered as an authorized tenant in the system
* **No Wallet**: The system doesn't have a wallet available for the authentication process

Each of these errors will trigger the progressive delay mechanism to suppress brute force attacks.


# fetch

Published: March 2025 | Last updated: March 2025

## fetch

### Overview

The `fetch` RPC method allows you to retrieve files that have been stored on the Lynx blockchain. It provides a mechanism for accessing data by its unique identifier (UUID) and saving it to a specified location on your filesystem. No authentication is required prior to using this function.

### Syntax

```
fetch <uuid> <path> [pubkeyflag]
```

### Description

When you invoke the `fetch` method, the Lynx daemon searches the blockchain for the specified file and downloads it to your designated location. This method is part of the core functionality that enables Lynx to serve as a decentralized data storage solution.

### Parameters

<table><thead><tr><th width="150.99609375">Parameter</th><th width="131.76953125">Type</th><th width="122.23046875">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>uuid</code></td><td>string</td><td>Yes</td><td>The unique identifier of the file you want to retrieve. This is a 64-character hexadecimal string (e.g., 2cf6eabc7af83152d5ad7d4ff9aeeb66f81dde70731b800bb0cd18300d9cb402).</td></tr><tr><td><code>path</code></td><td>string</td><td>Yes</td><td>The full filesystem path where the retrieved file should be stored (e.g., <code>/home/username/downloads</code>). This path must exist before calling the method.</td></tr><tr><td><code>pubkeyflag</code></td><td>string</td><td>No</td><td>Optional parameter that controls tenant public key inclusion in the response. Enter <code>0</code> to omit the tenant information. Default is <code>1</code> (include tenant information).</td></tr></tbody></table>

### Returns

The method returns an array containing a single object with the following fields:

<table><thead><tr><th width="150.33203125">Field</th><th width="183.3828125">Type</th><th>Description</th></tr></thead><tbody><tr><td><code>result</code></td><td>string</td><td>Indicates whether the operation succeeded (<code>success</code>) or failed (<code>failure</code>).</td></tr><tr><td><code>message</code></td><td>string</td><td>Provides additional information about the result. For successful operations, returns <code>n/a</code>. For failures, indicates the reason (e.g., <code>Invalid path /path/to/directory.</code>, <code>Invalid UUID length.</code>, <code>UUID not found.</code>).</td></tr><tr><td><code>tenant</code></td><td>string/number</td><td>When authentication is active and <code>pubkeyflag</code> is set to <code>1</code>, displays the tenant public key associated with the file. Otherwise returns <code>n/a</code>.</td></tr></tbody></table>

### Examples

#### Retrieve a specific file

Retrieve the file with UUID 2cf6eabc7af83152d5ad7d4ff9aeeb66f81dde70731b800bb0cd18300d9cb402 and store it in the `/home/username/downloads` directory:

```
lynx-cli fetch 2cf6eabc7af83152d5ad7d4ff9aeeb66f81dde70731b800bb0cd18300d9cb402 /home/username/downloads
```

Or using JSON-RPC:

```
curl --user username --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "fetch", "params": ["2cf6eabc7af83152d5ad7d4ff9aeeb66f81dde70731b800bb0cd18300d9cb402", "/home/username/downloads"]}' -H 'content-type: text/plain;' http://127.0.0.1:9332/
```

#### Retrieve a file without tenant verification

This method is significantly faster. Retrieve a file without performing tenant verification:

```
lynx-cli fetch 2cf6eabc7af83152d5ad7d4ff9aeeb66f81dde70731b800bb0cd18300d9cb402 /home/username/downloads 0
```

### Error Handling

The method will return a failure result in the following scenarios:

* The specified path doesn't exist on the filesystem
* The UUID has an invalid length (must be 64 characters for a specific file)


# fetchall

Published: March 2025 | Last updated: March 2025

### Overview

The `fetchall` RPC method allows you to retrieve multiple files from the Lynx blockchain in reverse chronological order (newest first). This command is useful for backing up or migrating data, as it can download either a specific number of the most recent files or all files stored on the blockchain for the authenticated tenant. Authentication is required to execute this function.

### Syntax

```
fetchall <count> <path>
```

### Description

When you invoke the `fetchall` method, the Lynx daemon searches the blockchain for the most recent files and downloads them to your designated location. The files are retrieved in reverse chronological order, meaning the newest files are fetched first. This method requires authentication and is designed for bulk retrieval operations.

### Parameters

<table><thead><tr><th width="134.2734375">Parameter</th><th width="159.03515625">Type</th><th width="124.90625">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>count</code></td><td>string/integer</td><td>Yes</td><td>The number of most recent assets to fetch. Enter <code>0</code> to retrieve all assets stored on the blockchain.</td></tr><tr><td><code>path</code></td><td>string</td><td>Yes</td><td>The full filesystem path where the retrieved files should be stored (e.g., <code>/home/username/downloads</code>). This path must exist before calling the method.</td></tr></tbody></table>

### Returns

The method returns an array containing a single object with the following fields:

<table><thead><tr><th width="152.83203125">Field</th><th width="123.2734375">Type</th><th>Description</th></tr></thead><tbody><tr><td><code>result</code></td><td>string</td><td>Indicates whether the operation succeeded (<code>success</code>) or failed (<code>failure</code>).</td></tr><tr><td><code>message</code></td><td>string</td><td>Provides additional information about the result. For successful operations, shows the number of assets fetched (e.g., <code>Number of assets fetched: 5</code>). For failures, indicates the reason (e.g., <code>Invalid path: /path/to/directory.</code>, <code>Not authenticated.</code>, <code>Invalid count: abc.</code>).</td></tr></tbody></table>

### Authentication Requirements

The `fetchall` command requires authentication:

* You must authenticate using the `auth` command before using `fetchall`
* If not authenticated, the method will return a "Not authenticated" error

### Examples

#### Retrieve the 5 most recent files

```
lynx-cli fetchall 5 /home/username/downloads
```

Output:

```
[
  {
    "result": "success",
    "message": "Number of assets fetched: 5"
  }
]
```

#### Retrieve all files stored on the blockchain

```
lynx-cli fetchall 0 /home/username/downloads
```

Using JSON-RPC:

```
curl --user username --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "fetchall", "params": ["5", "/home/username/downloads"]}' -H 'content-type: text/plain;' http://127.0.0.1:9332/
```

### Error Handling

The method will return a failure result in the following scenarios:

* The user is not authenticated
* The specified path doesn't exist on the filesystem
* The count parameter is not a valid integer

### Implementation Notes

* There is a 2-second pause between each file retrieval to prevent overwhelming the system
* The count parameter is converted to an integer with input validation to prevent errors


# store

Published: March 2025 | Last updated: March 2025

### Overview

The `store` RPC method allows you to upload and store files on the Lynx blockchain. This command is part of Lynx's decentralized file storage system, enabling users to persistently store data in a distributed manner.

### Syntax

```
store <filepath> [uuid]
```

### Description

When you invoke the `store` method, the Lynx daemon reads the specified file from your filesystem, processes it for blockchain storage, and initiates a storage transaction. The file is sharded appropriately and stored across multiple blockchain transactions, with a unique identifier (UUID) assigned to enable future retrieval.

### Parameters

<table><thead><tr><th>Parameter</th><th width="130">Type</th><th width="117">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>filepath</code></td><td>string</td><td>Yes</td><td>The full path to the file you want to store on the blockchain (e.g., <code>/home/username/documents/research.pdf</code>). The file must exist and have a size greater than zero bytes.</td></tr><tr><td><code>uuid</code></td><td>string</td><td>No</td><td>An optional custom unique identifier for the file. If provided, it must be 32 characters in hexadecimal format and must not already exist on the blockchain. If omitted, a random UUID will be automatically generated.</td></tr></tbody></table>

### Returns

The method returns an array containing a single object with the following fields:

<table><thead><tr><th width="201">Field</th><th width="142">Type</th><th>Description</th></tr></thead><tbody><tr><td><code>result</code></td><td>string</td><td>Indicates whether the operation succeeded (<code>success</code>) or failed (<code>failure</code>).</td></tr><tr><td><code>message</code></td><td>string</td><td>Provides additional information about the result. For successful operations, returns <code>n/a</code>. For failures, indicates the reason (e.g., <code>Not authenticated as tenant</code>, <code>Not authenticated</code>, <code>A duplicate unique identifier was discovered</code>, <code>The custom unique identifier provided has an invalid length</code>, <code>Invalid UUID hex notation</code>, <code>Zero length asset filesize</code>).</td></tr><tr><td><code>identifier</code></td><td>string</td><td>The UUID assigned to the file. For successful operations, this is either the custom UUID you provided or an automatically generated one. For failures, returns <code>n/a</code> unless the failure is related to an invalid custom UUID.</td></tr><tr><td><code>tenant</code></td><td>string</td><td>The authenticated user's public key hash. For authentication failures, returns <code>n/a</code>.</td></tr><tr><td><code>filesize</code></td><td>number</td><td>The size of the stored file in bytes. For failures, returns <code>0</code>.</td></tr><tr><td><code>storagefee</code></td><td>string/number</td><td>The storage transaction fee in Lynx. The fee is calculated as one liv per byte (filesize / 100,000,000 Lynx). For failures, returns <code>0</code>.</td></tr><tr><td><code>storagetime</code></td><td>string</td><td>The timestamp when the storage operation was performed, in <code>YYYY-MM-DD HH:MM:SS</code> format. For failures, returns <code>n/a</code>.</td></tr><tr><td><code>currentblock</code></td><td>number</td><td>The current blockchain height at the time of the operation.</td></tr><tr><td><code>stakingstatus</code></td><td>string</td><td>Indicates whether staking is currently <code>enabled</code> or <code>disabled</code> on the node.</td></tr></tbody></table>

### Authentication Requirements

The `store` method requires authentication:

* The Tenant must authenticate using the appropriate credentials before using this command
* Authentication sessions expire after 6 hours (21,600 seconds)

### Error Handling

The method will return a failure result in the following scenarios:

* The user is not authenticated or the authentication session has expired
* The custom UUID already exists on the blockchain
* The custom UUID has an invalid length (must be 32 characters)
* The custom UUID contains non-hexadecimal characters
* The file has zero length or doesn't exist

### Examples

#### Store a file with an automatically generated UUID

```
lynx-cli store /home/username/documents/research.pdf
```

Or using JSON-RPC:

```
curl --user username --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "store", "params": ["/home/username/documents/research.pdf"]}' -H 'content-type: text/plain;' http://127.0.0.1:9332/
```

#### Store a file with a custom UUID

```
lynx-cli store /home/username/documents/research.pdf 00112233445566778899aabbccddeeff
```

### Implementation Notes

* The method adds the storage task to a queue rather than performing a synchronous upload
* Files are stored with one liv per byte as the transaction fee
* The system automatically generates a UUID if none is provided
* Custom UUIDs are validated for length, hexadecimal format, and uniqueness
* The current blockchain height and staking status are included in all responses


# status

Published: March 2025 | Last updated: March 2025

### Overview

The `status` RPC method provides diagnostic information about the blockchain storage system's operational state. It shows the current condition of the storage worker and lists the most recent storage jobs (both completed and in progress). This command is essential for monitoring system health and troubleshooting issues with file storage operations.

### Syntax

```
status
```

### Description

When you invoke the `status` method, the Lynx daemon checks the current state of the storage worker process and retrieves information about recent jobs from the work queue. This gives you immediate visibility into the system's activity and helps identify potential bottlenecks or errors in the storage subsystem. The information is particularly valuable when diagnosing problems with `store` or `fetch` operations that may appear unresponsive.

### Parameters

This method does not accept any parameters.

### Returns

The method returns an array containing the worker status and recent job information:

```
[
  "WORKER_IDLE",
  "00112233445566778899aabbccddeeff, Fetch operation completed successfully",
  "aabbccddeeff00112233445566778899, Store operation failed: file not found",
  ...
]
```

The array contains the following elements:

1. **First element**: The current status of the storage worker, which will be one of:
   * `WORKER_IDLE` - The worker is available and ready to process new storage jobs
   * `WORKER_BUSY` - The worker is currently processing a storage job
   * `WORKER_ERROR` - The worker has encountered an error and may need attention
2. **Subsequent elements**: The most recent job results (up to 15 entries), with each entry containing:
   * The UUID of the file involved in the operation
   * A status message describing the result of the operation

The job list is ordered chronologically with the most recent jobs appearing last in the array.

### Usage Notes

* No authentication is required to use this command, making it useful for basic system diagnostics
* The command only shows the most recent 15 job results to prevent overwhelming output
* You can use this command to verify if the storage worker is available before submitting large storage jobs
* If the worker shows `WORKER_ERROR` status, you may need to restart the daemon to resolve issues

### Examples

#### Check the current system status

```
lynx-cli status
```

Output when the system is idle:

```
[
  "WORKER_IDLE",
  "00112233445566778899aabbccddeeff, Fetch completed",
  "aabbccddeeff00112233445566778899, Store completed"
]
```

Output when the system is processing jobs:

```
[
  "WORKER_BUSY",
  "00112233445566778899aabbccddeeff, Fetch completed",
  "aabbccddeeff00112233445566778899, Store in progress"
]
```

Using JSON-RPC:

```
curl --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "status", "params": []}' -H 'content-type: text/plain;' http://127.0.0.1:9332/
```

### Implementation Notes

* The system maintains a history of job results that persists until the daemon is restarted
* Only the most recent 15 job results are displayed to keep the output manageable
* While this command provides operational status, it does not include detailed performance metrics


# list

Published: March 2025 | Last updated: March 2025

### Overview

The `list` RPC method retrieves metadata for files stored on the Lynx blockchain by the authenticated tenant. This command provides a comprehensive view of all your stored files, arranged chronologically with the most recently stored files appearing first in the results.

### Syntax

```
list [count]
```

### Description

When you invoke the `list` method, the Lynx daemon scans the blockchain for files associated with your tenant account and retrieves metadata about each file. This includes the unique identifier, file size, storage location, and timestamp information. This command is essential for managing your blockchain-stored files and serves as a directory service for your decentralized storage.

### Parameters

<table><thead><tr><th>Parameter</th><th width="142">Type</th><th width="106">Required</th><th>Description</th></tr></thead><tbody><tr><td><code>count</code></td><td>string/integer</td><td>No</td><td>The maximum number of file records to retrieve. If omitted, the default is 10 records. To retrieve more files, you can specify a high number or 0 for all files.</td></tr></tbody></table>

### Returns

The method returns a nested array structure containing file metadata:

```
[
  [
    {
      "uuid": "00112233445566778899aabbccddeeff",
      "length": 12345,
      "height": 987654,
      "timestamp": "2023-05-15 14:30:22"
    },
    {
      "uuid": "aabbccddeeff00112233445566778899",
      "length": 54321,
      "height": 987650,
      "timestamp": "2023-05-14 09:15:37"
    },
    ...
  ]
]
```

Each file entry contains the following fields:

| Field       | Type   | Description                                                                                                                                                |
| ----------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `uuid`      | string | The unique identifier of the file. This is a 32-character hexadecimal string that serves as the primary reference for the file in the Lynx storage system. |
| `length`    | number | The total size of the file in bytes. This represents the complete file size, even if the file data is distributed across multiple blockchain blocks.       |
| `height`    | number | The starting block number where the file storage began. Files may span multiple blocks depending on their size.                                            |
| `timestamp` | string | The date and time when the file storage operation was initiated, in `YYYY-MM-DD HH:MM:SS` format.                                                          |

### Authentication Requirements

The `list` method requires user authentication:

* You must authenticate using the appropriate credentials before using this command
* If not authenticated, the method will return a simple "Not authenticated" message
* The method only retrieves files associated with the authenticated tenant

### Performance Considerations

* The `list` command scans the blockchain to find files, which can be resource-intensive
* For large storage histories, limiting the results with the `count` parameter can improve performance
* The command logs the execution time to the debug log, which can be useful for monitoring performance
* The default limit of 10 recent files helps optimize performance for routine usage

### Examples

#### List the 10 most recently stored files (default)

```
lynx-cli list
```

Or using JSON-RPC:

```
curl --user username --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "list", "params": []}' -H 'content-type: text/plain;' http://127.0.0.1:9332/
```

#### List the 5 most recently stored files

```
lynx-cli list 5
```

#### List all stored files

```
lynx-cli list 0
```

### Implementation Notes

* Only files with complete metadata (file length > 0) are included in the results
* The command measures and logs its execution time for performance monitoring
* The results are presented with the most recent files first (chronological order, newest to oldest)


# tenants (restricted)

Published: March 2025 | Last updated: March 2025

### Overview

The `tenants` RPC method displays the current list of registered data storage tenants on the Lynx blockchain. This command provides visibility into all user accounts that have permission to store data on the blockchain, helping administrators manage storage access rights within the system.

### Syntax

```
tenants
```

### Description

When you invoke the `tenants` method, the Lynx daemon retrieves and displays the complete list of registered storage tenants from the authentication system. Each tenant is represented by their unique public key hash in hexadecimal format. This command is particularly useful for administrators who need to verify which accounts have storage privileges or audit the current tenant roster before making changes.

### Parameters

This method does not accept any parameters.

### Returns

The method returns an array of hexadecimal strings, where each string represents a tenant's public key hash:

```
[
  "1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t",
  "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0",
  ...
]
```

Each element in the array is a 40-character hexadecimal string representing the public key hash (RIPEMD-160) of a registered tenant. These identifiers correspond to the `tenant` field returned by other commands such as `store` and `fetch`.

### Access Control

{% hint style="danger" %}
The `tenants` command is restricted to administrative use only.
{% endhint %}

### Examples

#### List all registered tenants

For a blockchain manager:

```
lynx-cli tenants
```

Output:

```
[
  "1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t",
  "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0"
]
```

For a non-manager user:

```
Role-based restriction: Current role cannot perform this action
```

Using JSON-RPC:

```
curl --user manager:password --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "tenants", "params": []}' -H 'content-type: text/plain;' http://127.0.0.1:9332/
```

### Implementation Notes

* No additional metadata about tenants is provided beyond their public key hashes
* This command does not modify the tenant list; it only displays the current state


# deny (restricted)

Published: March 2025 | Last updated: March 2025

### Overview

The `deny` RPC method revokes a tenant's authorization from the Lynx blockchain storage system. This command allows the blockchain manager to remove storage privileges from existing tenants, preventing them from further authentication and data storage operations. The revocation is recorded on the blockchain as a permanent record, ensuring the network consistently enforces access controls.

### Syntax

```
deny <hash160>
```

### Description

When you invoke the `deny` method as the blockchain manager, the Lynx daemon creates and broadcasts a special revocation transaction that removes a tenant from the authorized list. Similar to the authorization process, this revocation is implemented as a blockchain transaction containing a timestamped payload with the tenant's identifier and a revocation flag. Once this transaction is confirmed, the specified tenant can no longer authenticate or perform storage operations.

This command is the counterpart to the `allow` command and completes the lifecycle management of tenant authorizations. Together, these commands provide the blockchain manager with complete control over who can utilize the blockchain storage system.

### Parameters

| Parameter | Type   | Required | Description                                                                                                                                                                                                           |
| --------- | ------ | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `hash160` | string | Yes      | The RIPEMD-160 hash of the tenant's public key in hexadecimal format. This is a 40-character hexadecimal string (e.g., `00112233445566778899aabbccddeeff00112233`) that uniquely identifies the tenant to be removed. |

### Returns

The method returns a string indicating the result of the operation:

* `success` - The tenant has been successfully removed from the system
* `hash160-wrong-size` - The provided hash is not the correct length (must be 40 hexadecimal characters)
* `Role-based restriction: Current role cannot perform this action` - The authenticated user is not the blockchain manager
* `error-generating-authpayload` - An error occurred while generating the authentication payload
* `error-generating-authtransaction` - An error occurred while creating the authentication transaction
* `failure` - A general failure occurred, which typically indicates an authentication problem

### Access Control

The `deny` command has strict access control requirements:

* Only the blockchain manager (initial authentication user defined in consensus parameters) can execute this command
* The manager must be authenticated via the `auth` command before using `deny`
* Regular tenants cannot revoke access for themselves or other tenants
* This role-based restriction ensures centralized control over tenant authorization management

### Revocation Transaction

When a tenant's access is revoked, the system:

1. Generates a special authentication payload containing:
   * Operation type (1 for revoking a tenant, as opposed to 0 for adding)
   * Current timestamp
   * The tenant's hash160 identifier
2. Creates a blockchain transaction with this payload embedded as an OP\_RETURN output
3. Broadcasts this transaction to the network, where it will be mined into a block

This transaction serves as a permanent, immutable record of tenant revocation that all nodes can verify.

### Examples

#### Revoke a tenant's access

As the blockchain manager:

```
lynx-cli deny 00112233445566778899aabbccddeeff00112233
```

Output:

```
success
```

Using JSON-RPC:

```
curl --user manager:password --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "deny", "params": ["00112233445566778899aabbccddeeff00112233"]}' -H 'content-type: text/plain;' http://127.0.0.1:9332/
```

### Error Handling

The method will return a failure message in the following scenarios:

* The provided hash160 is not exactly 40 characters long (20 bytes in hexadecimal)
* The user is not authenticated or is not authenticated as the blockchain manager
* There is an error in generating the authentication payload or transaction
* The authentication system cannot validate the current user's credentials

### Implementation Notes

* The command verifies the user's authentication status using the `is_auth_member` function
* It validates that the authenticated user is the blockchain manager using consensus parameters
* The operation type is set to 1 (for revocation), as opposed to 0 (for authorization)
* The current timestamp is obtained using `TicksSinceEpoch<std::chrono::seconds>(GetAdjustedTime())`
* The authentication payload is generated with the `generate_auth_payload` function
* The authentication transaction is created and broadcast with the `generate_auth_transaction` function
* Unlike the `allow` command which returns an array, this command returns a simple string response

### Tenant Access After Revocation

When a tenant's access is revoked:

* The tenant can no longer authenticate using the `auth` command
* Any existing authentication sessions will continue until they expire (approximately 6 hours)
* Existing files stored by the tenant remain on the blockchain and can still be retrieved
* The tenant will no longer appear in the list returned by the `tenants` command

This behavior ensures that revocation prevents future access while preserving existing data integrity.


# allow (restricted)

Published: March 2025 | Last updated: March 2025

### Overview

The `allow` RPC method adds a new authorized tenant to the Lynx blockchain storage system. This command enables the blockchain administrator to grant storage privileges to new tenants by registering their public key hash in the authentication system. Once added, the new tenant can authenticate and begin storing data on the blockchain.

### Syntax

```
allow <hash160>
```

### Description

When you invoke the `allow` method as the blockchain manager, the Lynx daemon creates and broadcasts a special transaction containing authentication data that registers a new tenant in the system. This transaction includes a timestamped payload with the tenant's identifier, which is permanently recorded on the blockchain. This process establishes an immutable record of tenant authorization that can be verified by all nodes in the network.

The authorization process is designed with strong access controls to ensure that only the designated blockchain manager can add new tenants, protecting the integrity of the storage system's authentication mechanism.

### Parameters

| Parameter | Type   | Required | Description                                                                                                                                                                                                 |
| --------- | ------ | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `hash160` | string | Yes      | The RIPEMD-160 hash of the new tenant's public key in hexadecimal format. This is a 40-character hexadecimal string (e.g., `00112233445566778899aabbccddeeff00112233`) that uniquely identifies the tenant. |

### Returns

The method returns an array containing one or more status messages:

For successful operations:

```
[
  "success",
  "00112233445566778899aabbccddeeff00112233"
]
```

For failed operations, the array will contain a descriptive error message indicating the reason for failure:

```
[
  "hash160-wrong-size"
]
```

Possible status messages include:

* `success` - The tenant has been successfully added to the system
* `hash160-wrong-size` - The provided hash is not the correct length (must be 40 hexadecimal characters)
* `Role-based restriction: Current role cannot perform this action` - The authenticated user is not the blockchain manager
* `error-generating-authpayload` - An error occurred while generating the authentication payload
* `error-generating-authtransaction` - An error occurred while creating the authentication transaction
* `authentication failure` - The user is not authenticated or the authentication has expired
* `failure` - A general failure occurred (rarely seen, as more specific errors are usually provided)

### Access Control

The `allow` command has strict access control requirements:

* Only the blockchain manager (initial authentication user defined in consensus parameters) can execute this command
* The manager must be authenticated via the `auth` command before using `allow`
* Regular tenants cannot add other tenants, even if they are authenticated
* This role-based restriction ensures centralized control over tenant authorization

### Authentication Transaction

When a new tenant is added, the system:

1. Generates a special authentication payload containing:
   * Operation type (0 for adding a tenant)
   * Current timestamp
   * The tenant's hash160 identifier
2. Creates a blockchain transaction with this payload embedded as an OP\_RETURN output
3. Broadcasts this transaction to the network, where it will be mined into a block

This transaction serves as a permanent, immutable record of tenant authorization that all nodes can verify.

### Examples

#### Add a new tenant

As the blockchain manager:

```
lynx-cli allow 00112233445566778899aabbccddeeff00112233
```

Output:

```
[
  "success",
  "00112233445566778899aabbccddeeff00112233"
]
```

Using JSON-RPC:

```
curl --user manager:password --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "allow", "params": ["00112233445566778899aabbccddeeff00112233"]}' -H 'content-type: text/plain;' http://127.0.0.1:9332/
```

### Error Handling

The method will return a failure message in the following scenarios:

* The provided hash160 is not exactly 40 characters long (20 bytes in hexadecimal)
* The user is not authenticated or is not authenticated as the blockchain manager
* There is an error in generating the authentication payload or transaction
* The authentication system cannot validate the current user's credentials

### Implementation Notes

* The command verifies the user's authentication status using the `is_auth_member` function
* It validates that the authenticated user is the blockchain manager using consensus parameters
* The current timestamp is obtained using `TicksSinceEpoch<std::chrono::seconds>(GetAdjustedTime())`
* The authentication payload is generated with the `generate_auth_payload` function
* The authentication transaction is created and broadcast with the `generate_auth_transaction` function
* The system performs validation checks on both the tenant identifier and the transaction creation process


# Understanding the Encryption Option

Published: March 2025 | Last updated: March 2025

When storing your files and information on the Lynx blockchain, you have an important choice to make: should you encrypt your data or not? This article explains what this choice means in simple terms and helps you decide when to use each option.

### What Does Encryption Mean for Your Data?

Think of encryption like a lockbox for your information. When you encrypt your data:

* Your information is scrambled by Lynx automatically before being stored on the blockchain - this happens regardless of whether you let Lynx generate a random asset UUID or you provide your own custom asset UUID value
* Only someone with the right "key" (in this case, your asset UUID) can unscramble and view it
* Even if someone discovers your data on the blockchain, they can't make sense of it without your key

Without encryption, your data is stored as-is. While still protected by our UUID obfuscation system (which hides the location of your data), the actual content remains in its original form.

### Your Asset UUID: Both Address and Key

Here's something crucial to understand: **The asset UUID functions as both its address and its decryption key.**

This means:

* When you store an encrypted file, the system uses your asset UUID to encrypt it
* When you retrieve the file, that same asset UUID is needed to decrypt it
* **If you share your asset UUID with someone, you're essentially giving them the key to unlock your data**

Think of it like sharing the address and key to a safety deposit box. Anyone who has this information can find and open the box.

Importantly, **the asset UUID itself is never stored directly on the blockchain**. This means it cannot be guessed or detected by examining the chain history. The only way someone can access your encrypted data is if you deliberately share the asset UUID with them.

### Keeping Your Data Secure

For encrypted assets that you want to keep private:

* Never share the asset UUID with untrusted parties
* Store your asset UUIDs securely, as losing them means losing access to your data
* Consider implementing your own system for tracking which asset UUIDs belong to which files

If you do need to share access to an encrypted file, be aware that sharing its asset UUID grants complete access to view the file's contents.

### When Should You Encrypt Your Data?

**Consider encryption when storing:**

* Sensitive company information
* Personal data
* Private documents
* Anything you wouldn't want others to potentially access

**You might skip encryption for:**

* Public information that doesn't need protection
* Data where quick access is more important than security
* Large files where performance matters more than privacy
* Information you plan to share widely anyway

### How to Choose Encryption When Storing Data

Enabling encryption is simple. When storing your data, you'll add a simple parameter:

```
lynx-cli store "filepath" encrypt=true
```

If you don't specify the 'encrypt' parameter, your data will be stored without encryption by default.

### What This Means for You

The power of choice is in your hands. By making encryption optional, we let you decide the right balance between security and performance for each piece of data you store. Just remember that for encrypted data, the security of your information depends on keeping your asset UUIDs private.


# Understanding Lynx Staking Wait Times

Published: November 2024 | Last updated: November 2024

### Key Points

* 30-block waiting period (approximately 150 minutes)
* Applies to both receiving and spending staked coins

### Staking Process Explained

#### Initial Deposit Wait Time

When you deposit coins into your staking wallet, there's a mandatory 30-block waiting period before:

* Your coins become eligible for staking
* Your wallet can begin participating in the staking process

#### Reward Maturity Period

After earning coins through staking:

* A 30-block maturity period must pass
* This takes approximately 150 minutes
* Coins are locked during this period
* After maturity, coins become available for sending or further staking

### Improved Efficiency

The 30-block waiting period represents a significant improvement over the previous Proof of Work system:

* Previous system: Several months waiting time
* Current system: \~150 minutes
* Results in more efficient coin circulation
* Better user experience overall

### Common Question Addressed

**Q: "I deposited coins and enabled staking, but nothing is happening. Why?"**

This is normal. Here's what to expect:

1. After depositing coins, wait 30 blocks
2. Your wallet will automatically begin staking
3. Verify staking activity in your debug.log file:
   * Look for regular stake-related messages
   * Occasionally, you'll see notifications of blocks won by your node

### Monitoring Your Staking Activity

To confirm your wallet is staking properly:

1. Check your debug.log file
2. Look for consistent stake-related outputs
3. Monitor for successful block wins
4. Track your earned rewards

Remember: The 30-block waiting period applies to both new deposits and staking rewards, ensuring network security while maintaining efficient coin circulation.


# Understanding Asset Retrieval Times

Published: November 2024 | Last updated: November 2024

When building decentralized applications (dApps) or services that interact with the Lynx blockchain storage solution, understanding asset retrieval times is crucial for both system design and user experience optimization. This article analyzes the relationship between file sizes and fetch times, providing insights for developers and architects working with decentralized storage systems.

### Performance Analysis

Based on empirical measurements for an array of files, we can extrapolate performance characteristics across various file sizes. The data indicates a fetch transfer rate of approximately 30 MB/s (megabytes per second), which serves as our baseline for performance calculations.

#### Key Performance Metrics

| File Size | Fetch Time | Practical Implications                                          |
| --------- | ---------- | --------------------------------------------------------------- |
| 1 KB      | 0.000033s  | Instant retrieval for small metadata files                      |
| 1 MB      | 0.033s     | Quick fetch for documents and small images                      |
| 16 MB     | 0.533s     | Suitable for larger images and small video clips. Consider CDN. |
| 32 MB     | 1.067s     | Moderate wait time for high-quality media. Consider CDN.        |
| 64 MB     | 2.133s     | Notable delay for larger assets. Use CDN.                       |
| 128 MB    | 4.267s     | Significant wait time for large files. Use CDN.                 |

### Leveraging Asset Immutability

One of the key characteristics of blockchain-stored assets is their immutability - once stored, these digital assets never change. This immutability provides a unique opportunity for optimization through aggressive caching and content delivery strategies.

#### Benefits of Asset Immutability

* **Cache Forever:** Assets can be cached indefinitely without concerns about staleness
* **No Cache Invalidation:** Eliminate complex cache invalidation logic
* **Perfect Cache Hit Rates:** After initial fetch, subsequent requests always hit cache
* **Reduced Origin Load:** Minimal requests to blockchain storage nodes
* **Lower Costs:** Reduced bandwidth usage from storage nodes
* **Random Purge and Reload:** Ensures regular verification against blockchain source

#### Recommended Caching Architecture

For optimal performance with immutable blockchain assets:

1. **Edge CDN Layer**
   * Deploy assets to global CDN networks
   * Use permanent cache TTLs
   * Implement optimal geographic distribution
   * Consider multi-CDN strategies for redundancy
2. **Regional Cache Layer**
   * Deploy regional caching nodes
   * Implement permanent storage for frequently accessed assets
   * Use load balancing across cache nodes
3. **Local Application Cache**
   * Implement browser-level caching with Service Workers
   * Use IndexedDB or WebStorage for persistent local storage
   * Implement progressive web app (PWA) capabilities

### Implementation Considerations

#### 1. User Experience Design

When implementing asset retrieval in decentralized applications, consider these UX best practices:

* Implement progressive loading for larger files
* Show loading indicators for files >1MB
* Consider pre-fetching critical assets
* Cache frequently accessed files locally
* Implement retry mechanisms for failed fetches

#### 2. Performance Optimization Strategies

Given the immutable nature of blockchain-stored assets, implementing a robust caching strategy is crucial:

**Multi-Tier Caching Strategy**

1. **CDN Integration (Primary)**
   * Deploy assets to multiple CDN providers
   * Use permanent cache headers (Cache-Control: immutable, max-age=31536000)
   * Implement CDN fallback strategies
   * Consider cost-effective CDN routing based on asset popularity
   * Random purge and replenish
2. **Regional Cache Nodes (Secondary)**
   * Deploy cache nodes in high-demand regions
   * Implement permanent storage policies
   * Use content-addressable storage for efficient retrieval
   * Monitor cache hit rates and adjust distribution
   * Random purge and replenish
3. **Application-Level Caching**
   * Implement Service Worker caching
   * Use IndexedDB for large assets
   * Implement background sync capabilities
   * Consider peer-to-peer sharing for cached assets

Additional Optimizations:

* Use thumbnail previews for large media files
* Implement parallel downloading for multiple small files
* Consider file compression for initial storage
* Implement predictive pre-fetching based on user behavior

#### 3. Technical Limitations and Solutions

**Network Variability for Non-local RPC Implementation**

The fetch times presented assume consistent network conditions. In practice, several factors can affect retrieval times:

* Network congestion
* Node availability
* Geographic distance to storage nodes
* Network protocol overhead
* Chain state and consensus delays

**Optimization Techniques**

To mitigate these limitations:

* Implement adaptive bitrate streaming for video content
* Use lazy loading for non-critical assets
* Implement smart caching strategies
* Consider multi-node retrieval for larger files
* Use predictive pre-fetching for improved performance

### Conclusion

Understanding asset retrieval times is crucial for building effective decentralized applications. The linear relationship between file size and fetch time (30 MB/s) provides a reliable baseline for planning and implementing storage solutions. However, developers should account for network variability and implement appropriate optimization strategies based on their specific use cases.

By following these guidelines and implementing suggested optimization strategies, developers can create robust applications that provide a smooth user experience while efficiently handling blockchain-based asset retrieval.

### Technical Notes

* Base Transfer Rate: 30 MB/s from origin storage nodes
* Protocol Overhead: Varies by implementation
* Network Conditions: Results may vary based on network topology and conditions
* Storage Node Distribution: Geographic distribution affects initial retrieval times
* Caching: Implement permanent caching strategies leveraging asset immutability

Remember: With blockchain-stored assets being immutable, aggressive and permanent caching strategies are not just safe but highly recommended for optimal performance and cost efficiency.


# Understanding Block Time Targeting in the Lynx Blockchain

Published: January 2025 | Last updated: January 2025

In the Lynx blockchain, blocks are created approximately every five minutes through a Proof of Stake consensus mechanism. While this target time is consistent, the actual time between blocks (block time) can vary slightly due to network conditions and validator behavior. This document explains how our system maintains stable block times using Linear Weighted Moving Average (LWMA) difficulty adjustment.

### Block Time Basics

Block time is the average interval between the creation of consecutive blocks in a blockchain. In Lynx, the target block time is 5 minutes (300 seconds). This timing was chosen to balance several factors:

* Transaction confirmation speed
* Network synchronization efficiency
* Resource requirements for validators
* Storage block size propagation across the network

### How LWMA Maintains Target Block Time

The LWMA algorithm helps maintain consistent block times by adjusting the difficulty target based on recent block history. Here's how it works:

#### 1. Measuring Block Time

The system tracks the timestamp of each block and calculates the time difference between consecutive blocks. These measurements create a running history of actual block times.

#### 2. Weighted Average Calculation

Rather than using a simple average, LWMA applies greater weight to recent blocks and less weight to older blocks. This weighting helps the system respond more quickly to changing network conditions while preventing excessive fluctuations.

For example, if the last few blocks were created more quickly than the 5-minute target, the algorithm would increase the difficulty for the next block. Conversely, if recent blocks took longer than 5 minutes, the difficulty would decrease.

#### 3. Difficulty Adjustment

The difficulty target is adjusted based on the weighted average calculation:

* If blocks are being created too quickly, the difficulty increases
* If blocks are being created too slowly, the difficulty decreases
* The magnitude of adjustment is proportional to the deviation from the target time

### Why Block Times Fluctuate

Despite the LWMA algorithm, some variation in block times is normal and expected due to several factors:

#### Network Conditions

* Variable network latency
* Temporary network congestion
* Geographic distribution of validators

#### Validator Behavior

* Changes in the number of active validators
* Variations in validator stake amounts
* Temporary validator downtime

#### System Design

* Random elements in the block creation process
* Intentional flexibility to handle network stress
* Block propagation delays

### Advantages of Lynx's LWMA Approach

The Lynx implementation of LWMA provides several benefits:

1. Stability: The weighted average helps prevent dramatic swings in difficulty while still allowing necessary adjustments.
2. Responsiveness: Greater weight on recent blocks allows quick adaptation to changing network conditions.
3. Attack Resistance: The algorithm helps protect against time-warp attacks and difficulty manipulation attempts.
4. Smooth Transitions: Gradual difficulty adjustments help maintain network stability during periods of changing validator participation.

### Real-World Performance

In practice, the Lynx network maintains an average block time very close to the 5-minute target when measured over longer periods (days or weeks). Short-term variations typically stay within acceptable bounds:

* Most blocks: 4-6 minutes
* Occasional blocks: 1-10 minutes
* Rare cases: <10 seconds or >20 minutes

These variations are normal and do not impact the overall reliability or security of the blockchain.

### Conclusion

The 5-minute block time, maintained through LWMA difficulty adjustment, provides a robust foundation for the Lynx blockchain. While individual block times may vary, the system successfully maintains long-term stability while adapting to changing network conditions. This balance of consistency and flexibility helps ensure reliable operation of the blockchain while maintaining security and decentralization.


# Understanding the Lynx Blockchain Statistics Report

Published: January 2025 | Last updated: January 2025

The Lynx blockchain generates a statistical report in its debug log every 25 blocks after the Lynx daemon starts running. This means when you first start your Lynx node, it begins counting blocks from that moment, and after it has processed 25 new blocks, it produces its first statistical report. Each subsequent report comes after another 25 blocks have been processed. These reports provide crucial information about block creation timing across different time periods, helping node operators monitor the health and performance of the network.

### Report Format

The report presents data in the following format:

```
Block Statistics - last hour: 295s (13 blocks), day: 307s (283 blocks), week: 305s (1981 blocks), fortnight: 305s (3973 blocks), month: 304s (7947 blocks)
```

### Understanding Each Metric

#### Last Hour Statistics

`last hour: 295s (13 blk)`

* The average block time in the last hour was 295 seconds
* 13 blocks were created during this period
* This helps identify very recent network performance

#### Daily Statistics

`day: 307s (283 blk)`

* The average block time over the last 24 hours was 307 seconds
* 283 blocks were created during this period
* This provides a view of short-term network stability

#### Weekly Statistics

`week: 305s (1981 blk)`

* The average block time over the last 7 days was 305 seconds
* 1981 blocks were created during this period
* This shows medium-term network performance trends

#### Fortnightly Statistics

`fortnight: 305s (3973 blk)`

* The average block time over the last 14 days was 305 seconds
* 3973 blocks were created during this period
* This provides additional context for medium-term trends

#### Monthly Statistics

`month: 304s (7947 blk)`

* The average block time over the last 30 days was 304 seconds
* 7947 blocks were created during this period
* This represents long-term network performance

### Interpreting the Data

#### Target Analysis

Remember that Lynx targets a 300-second (5-minute) block time. In the example:

* The hourly average (295s) is very close to target
* The daily average (307s) shows strong stability near the target
* The longer-term averages show slight deviation, which is normal

#### Network Health Indicators

This report helps identify:

* Short-term network conditions (hourly/daily metrics)
* Long-term stability trends (weekly/monthly metrics)
* Potential network issues (significant deviations from expected values)
* Block production consistency across different timeframes

### Important Considerations

* The report updates every 25 blocks, providing regular network health snapshots
* Short-term fluctuations are normal and expected
* Longer-term averages should trend toward the 300-second target
* Block counts help verify network participation and consensus
* Multiple timeframes help distinguish between temporary fluctuations and systemic issues


# Spark: The Simple Way to Run a Lynx Node

Published: April 2026 | Last updated: May 2026

## Spark: The Simple Way to Run a Lynx Node

### Overview

Spark is the easiest way to run a Lynx node on your own hardware. It's a single installer script that takes a fresh Linux machine — a Raspberry Pi, a small cloud server, an old laptop tucked in a closet — and turns it into a fully configured node on the Lynx Data Storage Network.

You don't need to compile software, edit config files, or learn systemd. You paste one line into a terminal, and Spark does the rest: downloads the right binaries for your hardware, sets up the daemon, configures the firewall, and gives you a friendly set of short commands for day-to-day use.

Spark is deliberately designed for modest hardware. It's happy on a Raspberry Pi with 2GB of RAM or a budget VPS — the kind of machine that couldn't handle a heavy dashboard application but has more than enough capacity to contribute to the network and even earn staking rewards.

<figure><img src="/files/H1UAAroI3gk3aXk1buEr" alt="A picture of several Raspberry Pi Zero 2 devices on a USB power hub." width="375"><figcaption><p>Staking farm with Raspberry Pi Zero 2 devices on a USB power hub.</p></figcaption></figure>

### What Spark Does for You

When you run the Spark installer, it takes care of everything a node needs to operate reliably:

* **Installs the right software** — detects whether you're on an AMD or ARM system and downloads the matching Lynx daemon from the official releases
* **Sets up the daemon as a background service** — the node starts automatically when your machine boots and stays running in the background
* **Configures the firewall** — opens the ports Lynx needs and closes the ones it doesn't
* **Secures remote access** — tightens SSH settings so your machine is harder to attack
* **Handles low memory gracefully** — if your machine is small, Spark notices when the node gets stuck during the initial download and gives it a nudge
* **Creates automatic wallet backups** — your wallet file is copied to a safe location on a schedule, so a corrupted SD card won't cost you your coins
* **Installs a friendly command shortcut system** — instead of typing long blockchain commands, you get short aliases like `gba` (get balance), `lyr` (restart daemon), `s` (toggle staking on/off), and `h` (help)

Once installation finishes, you log in and see a welcome screen with your node's current status, a list of the commands you can use, and your staking performance for the last 24 hours and 7 days.

### Spark vs. Beacon

Lynx offers two tools for running nodes. They connect to the same network and both can run more than one chain on a single machine — the difference is how they feel to use and what hardware they're aimed at.

|                       | Spark                                                                                         | Beacon                                              |
| --------------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------- |
| **Interface**         | Short typed commands (like `gba`, `lyr`, `h`)                                                 | Full-screen interactive dashboard                   |
| **Hardware**          | Happy on Raspberry Pis, old laptops, small VPSs                                               | Wants a bit more breathing room                     |
| **Style**             | Minimal and efficient; nothing running unless you ask                                         | Richer, more convenient, more fun to watch          |
| **Wallet encryption** | Not built in — advanced users can still encrypt their wallet directly with the underlying CLI | Built-in wallet encryption                          |
| **ElectrumX server**  | Not included                                                                                  | Built-in ElectrumX installer                        |
| **Best for**          | Set-and-forget nodes on modest hardware                                                       | Operators who want a live cockpit for their daemons |

If you're reading this guide on a phone while waiting for a Raspberry Pi to boot, Spark is probably what you want. If you're the sort of person who leaves `htop` open all day — or you need wallet encryption or an ElectrumX server without assembling it yourself — Beacon might be a better fit.

### What You'll Need

#### Hardware

* A computer running Linux — a Raspberry Pi 4 (2GB), a small cloud server, or any AMD or ARM machine
* At least 2GB of RAM recommended (Spark can work with less, even a Pi Zero 2, but it's slower)
* At least 32GB of storage (64GB or more is better for long-term use)
* A reliable internet connection

#### Software

Spark runs on most common Linux distributions:

* **Debian family**: Debian, Ubuntu, Raspberry Pi OS
* **RedHat family**: Rocky Linux, AlmaLinux, CentOS, Fedora

#### Access

* Root access (the ability to run commands as the administrator)
* The `curl` command — if it's missing, install it with `apt install curl` on Debian/Ubuntu or `dnf install curl` on RedHat systems

If any of that sounded intimidating, don't worry. Most fresh installs of the supported systems already have everything you need.

### Installing Spark

#### The One-Line Install

Log in to your machine as root (or use `sudo su` to switch to root), then paste this command:

```bash
bash <(curl -sL install.getlynx.io)
```

That's the whole thing. The script will run for a few minutes — downloading Lynx, setting up services, configuring the firewall, and writing the command shortcuts to your shell. You'll see progress messages along the way.

When it finishes, log out and log back in. You'll be greeted by the Spark console, which shows your node's status and all the commands available to you.

#### Running a Different Chain

Lynx is a platform — there are multiple chains that run on the same technology. If you want to run a chain other than the default, add `--chain=` followed by the chain's name:

```bash
bash <(curl -sL install.getlynx.io) --chain=mychain
```

If the chain you picked doesn't have a binary released yet, Spark will tell you and stop without breaking anything.

#### Running Multiple Chains on One Machine

<figure><img src="/files/B2dVVigujjBdbRxEZ05Q" alt="" width="375"><figcaption></figcaption></figure>

You can run more than one chain on the same host. Just run the installer once for each chain you want, giving a different `--chain=` name each time:

```bash
bash <(curl -sL install.getlynx.io)                    # installs Lynx
bash <(curl -sL install.getlynx.io) --chain=otherchain # adds otherchain
```

Each chain gets its own daemon, its own data folder, and its own backup schedule. To switch between them in your shell, type:

```bash
chain        # shows a menu of installed chains
c            # same thing — just shorter
```

The menu doubles as a quick multi-chain dashboard. For each installed chain it shows the current wallet balance, the chain's block height, and whether staking is on or off — so a single keystroke gives you a status snapshot of every chain on the host before you pick one. Whichever chain you pick becomes the "active" one for your shell, meaning commands like `gba` (balance), `lyr` (restart), or `s` (toggle staking) will apply to that chain until you switch.

### Day-to-Day Use: The Spark Console

After installation, every time you log in as root you'll see the Spark console — a welcome screen that shows your node's real-time status and a menu of commands.

#### Node Status at a Glance

At the top you'll see things like:

* How many stakes you've won in the last 24 hours and 7 days
* Your recent yield rates as percentages
* Any coins still waiting to mature before you can stake or spend them
* Your current wallet balance
* The daemon version and Spark installer version

This information updates every time you type `h` (short for "help"), so you can always see what's happening without digging through logs.

#### The Most Useful Commands

You don't need to memorize these — typing `h` at any time brings up the full list. But here are the ones you'll use most:

**Checking on your node**

| Command | What it does                                                         |
| ------- | -------------------------------------------------------------------- |
| `h`     | Show the welcome screen and command list                             |
| `gbi`   | Show blockchain sync status                                          |
| `lss`   | Is the daemon running?                                               |
| `lyl`   | Show the last 30 lines of the daemon's log (`lyl -f` to follow live) |
| `jou`   | Show the installer's log — useful for troubleshooting setup issues   |

**Wallet basics**

| Command                  | What it does                               |
| ------------------------ | ------------------------------------------ |
| `gba`                    | Show your wallet balances                  |
| `gna`                    | Generate a new receiving address           |
| `sta <address> <amount>` | Send coins to an address (sender pays fee) |
| `swe`                    | Sweep a wallet (receiver pays fee)         |
| `bac`                    | Make an immediate wallet backup            |
| `lba`                    | List your backup folder                    |

**Managing the daemon**

| Command | What it does                                                       |
| ------- | ------------------------------------------------------------------ |
| `lyr`   | Restart the daemon (useful if it seems stuck)                      |
| `lyc`   | View the daemon's config file (`lyc -e` to edit)                   |
| `s`     | Toggle staking on or off for the active chain                      |
| `upd`   | Update the daemon to the latest version                            |
| `reb`   | Rebuild the Spark setup without touching your wallet or blockchain |

**Multi-chain**

| Command        | What it does                                                                                           |
| -------------- | ------------------------------------------------------------------------------------------------------ |
| `chain` or `c` | Show every installed chain with its balance, block height, and staking state — and switch between them |

### The First Few Hours

When you start a node for the first time, it needs to download the entire blockchain from the network before it can participate. This is called the **initial sync**, and it's the slowest part of the whole experience.

* **On a Raspberry Pi**: expect 4–8 hours depending on your internet speed
* **On a modern VPS**: often under 2 hours
* **On a slow or congested connection**: it may take longer — that's normal

You can check progress anytime with `gbi`. Look for the `blocks` and `headers` numbers — when they match, your node is fully caught up.

During sync, Spark runs a maintenance check every 12 minutes. If your machine is low on memory and the daemon gets stuck, Spark nudges it — this is completely normal and not a sign anything is wrong. Once sync completes, the maintenance check turns itself off and your node enters a quiet, low-resource steady state.

### Keeping Spark Up to Date

Two short commands handle updates:

* `upd` — updates the Lynx daemon to the latest release
* `reb` — rebuilds Spark's services, firewall rules, and command shortcuts (use this if Spark itself gets an update)

Neither of these touches your wallet or your downloaded blockchain data, so they're safe to run whenever you like.

### If Something Goes Wrong

A few go-to commands when things feel off:

* **Is the daemon running?** — `lss`
* **What has it been up to?** — `lyl -f` (press Ctrl+C to stop watching)
* **Did the installer do its job?** — `jou -f`
* **Have you tried turning it off and on again?** — `lyr`

If you're stuck, the Lynx community is active on Discord and happy to help. When you ask for help, it makes life easier for everyone if you paste the output of `h` along with your question.

### Where to Go Next

* **Official documentation**: <https://docs.getlynx.io/>
* **Blockchain explorer**: <https://explorer.getlynx.io/>
* **Permanent file storage**: <https://clevver.org/>
* **Community and support**: the Lynx Discord
* **Source code and issues**: <https://github.com/getlynx/Lynx>

### Conclusion

Spark is the fastest path from "I have a spare Linux machine" to "I'm running a node on the Lynx Data Storage Network." It's built for people who want their node to just work without a lot of hand-holding, and it's tuned for the kind of small, quiet hardware that's ideal for long-running infrastructure.

Paste one line. Come back in a few hours. Your node is live.


# Staking and Transaction Timing

Published: January 2025 | Last updated: March 2026

### Overview

Proof of Stake allows coin holders to earn rewards by keeping their wallet online and staking their coins to help secure the network. When your wallet successfully stakes a block, you receive newly minted coins as a reward plus any transaction fees included in that block. (In a traditional sense, think of it like your savings account is earning interest. The more money you have, the more interest you earn.) However, these staking rewards come with a maturity period requirement that can affect your ability to send transactions immediately. This document explains how staking works, why it can delay transactions, and how to manage your staking settings to avoid complications.

### How Staking Affects Transactions

When you earn a staking reward, those newly minted coins and collected transaction fees cannot be spent immediately. The network enforces a thirty-block maturity period before staked coins become spendable. This security measure ensures that if a staking block becomes orphaned due to a chain reorganization, the coins that would have been created by that block never enter circulation. Without this maturity requirement, users could spend coins that might later disappear from the blockchain, creating serious accounting problems.

With five-minute block times, the thirty-block maturity period translates to 150 minutes or approximately two and a half hours. During this window, any coins you earned from staking remain locked and cannot be included in outgoing transactions. If you attempt to send coins while a portion of your balance consists of immature staking rewards, you may encounter transaction delays or complications.

### Checking for Immature Coins

Before attempting to send a transaction, you can verify whether you have recently earned staking rewards by examining your debug log. The debug log records all Proof of Stake blocks your wallet has successfully staked. If you have not won any stakes in the previous thirty blocks (approximately 150 minutes), all your coins should be mature and available for immediate spending.

To check your staking activity, locate your debug log file at `~/.[daemon]/debug.log` and search for recent Proof of Stake entries. If you see staking activity within the last two and a half hours, you should wait for the maturity period to complete or temporarily disable staking before sending coins.

**Example for Lynx users:** Your debug log would be located at `~/.lynx/debug.log`. Search for entries indicating "New proof-of-stake block found" or "CheckStake()" to identify recent staking activity.

### Option 1: Send Without Disabling Staking

If your debug log shows no staking activity in the previous thirty blocks, you can send transactions immediately without changing any settings. Your coins are already mature and the staking process will not interfere with your transaction. This is the simplest approach when you have not recently earned staking rewards.

Simply execute your standard send command and your transaction will process normally. The staking thread continues running in the background but will not affect your transaction since all coins in your wallet have already matured.

### Option 2: Disable Staking Temporarily

If you need to send coins immediately but recently earned staking rewards, you can temporarily disable staking without restarting your wallet using the `setstaking` RPC command. This approach provides immediate control over the staking function and is ideal for one-time transactions.

To disable staking immediately, execute this command:

```
[daemon]-cli setstaking false
```

**Example for Lynx:** `lynx-cli setstaking false`

Once staking is disabled, wait for any immature coins to mature. You can monitor the maturity progress by checking the block height. Once thirty blocks have passed since your last stake, all coins become spendable and you can safely send your transaction.

To re-enable staking after completing your transaction, execute this command:

```
[daemon]-cli setstaking true
```

**Example for Lynx:** `lynx-cli setstaking true`

The `setstaking` command takes effect immediately without requiring a daemon restart. However, this setting is temporary and will revert to whatever is configured in your `[daemon].conf` file the next time you restart the wallet. Use this method when you need immediate control but don't want to permanently change your staking behavior.

To determine if the staker is enabled, you can execute the following command (with no argument). The response will be true (the staking thread is enabled and running) or false (staking is off and no staking effort is taking place).

```
[daemon]-cli setstaking
```

**Example for Lynx:** `lynx-cli setstaking`

### Option 3: Disable Staking Permanently

For users who frequently send transactions and want to avoid maturity delays altogether, you can permanently disable staking through the configuration file. This approach requires a daemon restart but provides a persistent setting that survives wallet restarts.

Open your configuration file located at `~/.[daemon]/[daemon].conf` and add or modify the `disablestaking` parameter:

```
disablestaking=1
```

**Example for Lynx:** Edit `~/.lynx/lynx.conf` and set `disablestaking=1`

After saving the configuration file, restart your daemon for the change to take effect. Staking will remain disabled until you change this setting back to `disablestaking=0` and restart again.

To re-enable staking permanently, change the parameter to:

```
disablestaking=0
```

Then restart the daemon. This configuration provides long-term control over staking behavior and is the recommended approach if you have a consistent preference for whether staking should be enabled or disabled.

### Understanding Transaction Delays and Stuck Transactions

When you attempt to send coins while a portion of your balance consists of immature staking rewards, your transaction may become stuck. This happens because the wallet attempts to construct a transaction using all available coins, including those that have not yet matured. The network rejects these transactions because immature coins cannot be spent, leaving your transaction unconfirmed in the mempool.

A stuck transaction can be alarming because it appears that your coins have been sent but the recipient never receives them. The transaction shows as pending in your wallet, reducing your available balance, but never confirms on the blockchain. This state can persist for up to twenty-four hours as network nodes simply hold it in their mempools until it expires. Eventually, all nodes drop the unconfirmed transaction from their mempools and your coins return to your spendable balance.

**Important:** Your coins are never lost during this process. The transaction failure is purely temporary and your full balance will be restored once the stuck transaction is abandoned or dropped by the network. However, the experience can cause significant confusion and concern, which is why following the proper procedure for managing staking and maturity is important.

### Resolving Stuck Transactions

If you have already sent a transaction that has become stuck due to immature coins, you can immediately resolve the issue using the `abandontransaction` command. This command tells your wallet to stop tracking the stuck transaction and return the coins to your available balance (this only applies to unconfirmed transactions).

To abandon a stuck transaction, you need the transaction ID (txid). You can find this in your wallet's transaction list or by checking recent transactions in your debug log. Once you have the txid, execute:

```
[daemon]-cli abandontransaction "txid"
```

**Example for Lynx:** `lynx-cli abandontransaction "a1b2c3d4e5f6..."`

Replace the quoted txid with your actual transaction identifier. After executing this command, your coins immediately become available again in your wallet. You can then follow the proper procedure of disabling staking, waiting for maturity, and sending your transaction again.

The `abandontransaction` command only affects your local wallet's tracking of the transaction. If the transaction was broadcast to the network, some nodes may still have it in their mempools, but it will eventually be dropped as unconfirmable. Your wallet will no longer attempt to rebroadcast it after you execute the abandon command.

### Best Practices for Managing Staking and Transactions

For users who actively stake and regularly send transactions, consider these approaches to minimize complications:

**For frequent senders:** Keep `disablestaking=1` in your configuration file and only enable staking during periods when you do not need to send transactions. This ensures your full balance is always immediately available for spending.

**For infrequent senders:** Leave staking enabled and check your debug log before sending transactions. If you have recently staked, wait the full 150-minute maturity period before sending, or temporarily disable staking using the `setstaking false` command.

**For maximum rewards:** Keep staking enabled at all times and plan your outgoing transactions around the maturity cycle. Check your last stake time, add 150 minutes, and schedule your sends after that window completes.

Understanding the relationship between staking, maturity, and transaction timing allows you to manage your wallet effectively while maximizing staking rewards and maintaining the ability to send coins when needed. The maturity requirement serves an important security function in Proof of Stake consensus, and working with this requirement rather than against it ensures smooth wallet operation.


# How to Sweep a Wallet

Published: January 2025 | Last updated: February 2026

### Understanding Wallet Sweeping

When managing cryptocurrency, there are times when you need to completely empty a wallet by transferring all funds to another address. This process is called "sweeping" the wallet. Sweeping is accomplished through a special transaction technique that ensures no unspent transaction outputs (UTXOs) remain in the source wallet.

### The Challenge of Sweeping

Normally, when sending cryptocurrency, the transaction fee is deducted from the sending wallet. This creates a challenge when trying to send exactly all funds, as you need to subtract the fee from the total amount. Depending on the complexity of the transaction, the fee can be difficult to calculate prior to execution. However, Lynx provides a solution to this problem by allowing the recipient to pay the transaction fee instead.

### How to Sweep a Wallet

#### Step 1: Check Your Balance

First, you need to know exactly how many coins are in your wallet. Use the getbalances RPC command:

```bash
[daemon]-cli getbalances
```

The response will look something like this:

```json
{
  "mine": {
    "trusted": 5010958.70982113,
    "untrusted_pending": 0.00000000,
    "immature": 0.00000000
  }
}
```

The "trusted" value shows your available balance. Be sure the *untrusted\_pending* and *immature* amounts equal zero. Make note of this exact number.

#### Step 2: Send All Funds

Use the sendtoaddress RPC command with these specific parameters:

```
[daemon]-cli sendtoaddress <recipient_address> <exact_balance> "" "" true
```

For example:

```
lynx-cli sendtoaddress KVgjrQdpYzjHKAhP4uXqaRJ7 5010958.70982113 "" "" true
```

Let's break down the parameters:

1. The recipient's Lynx address
2. The exact balance from Step 1
3. Empty comment ("")
4. Empty comment-to ("")
5. `true` to specify that the recipient pays the fee

### Understanding How It Works

This technique works because:

1. The `true` parameter at the end tells the network that the recipient will pay the transaction fee
2. Since the sender isn't paying the fee, you can specify the exact amount in your wallet
3. The network processes this as a special type of transaction where the fee is deducted from the receiving end
4. This ensures that every UTXO in the sending wallet is included in the transaction

### Important Considerations

* Always double-check the recipient address before sending
* Verify your balance immediately before sending to ensure accuracy
* Make sure your *untrusted\_pending* and *immature* coins are zero
* Once completed, the sending wallet will have a balance of exactly zero
* This operation cannot be undone, so proceed with caution
* Before deleting your source wallet, be sure to wait for a few block confirmations

### After the Sweep

After successfully sweeping your wallet:

1. The entire balance will be transferred to the recipient address
2. The transaction fee will be paid by the recipient
3. Your source wallet will show a zero balance
4. All UTXOs from your source wallet will be consumed

### Verifying the Sweep

To confirm the sweep was successful:

1. Check your wallet balance again using getbalances after a few blocks have passed
2. Look for the transaction in a [blockchain explorer](https://chainz.cryptoid.info/lynx/)
3. Verify the receiving address shows the correct balance minus the transaction fee

Remember that sweeping a wallet is a powerful operation that should be used carefully and only when you truly need to transfer all funds from one wallet to another. Always double-check your work and make sure you understand the implications before proceeding.


# Resetting a Network

Creating a new chain or resetting a specific network can be tedious. The following guide should save you time.

{% hint style="danger" %}
The instructions in this guide are only for developers and the Lynx Code Development Team. There is no situation where a user should execute these instructions to 'fix a bug.'
{% endhint %}

{% hint style="info" %}
A [video at the bottom of this article complements](#video-tutorial) this writing.
{% endhint %}

This guide is being created as a reference for developers looking to reset the Testnet network. Consensus parameters must be changed to create a new Mainnet blockchain, but this guide does not cover those changes.&#x20;

### Step 1: Preparing the target network

*Shut down all peers that operate on the target network.*

If you execute the following steps without shutting down all daemons on the network, your effort will be futile. You must be able to stop all daemons on the network to reset it. This is a feature of blockchain, not a bug. This design disallows a bad actor from executing these steps on the Mainnet network for a blockchain project since detected peers will have a longer chain length backed by a network of PoW or PoS hashing power.&#x20;

{% hint style="info" %}
Don't forget that with blockchain, the longest chain wins. If you don't shut down all nodes and your newly created node discovers a peer with a longer chain, the two will sync, and your short chain history will be reset and 'overwritten' by the longer peer chain history.
{% endhint %}

For your safety, after you shut down all the neighbor peers on the network, delete the chain history for those neighbor peers, too. The reason is that if a node is accidentally turned on later and still has the old chain history intact, it will disrupt your effort and force you to start over again. Save time by turning off all neighbor peers and deleting each node's blockchain data files. **All blockchain history will be lost, including coins possessed, transaction history, and data stored.** Be sure this is exactly your intention. Practice on a Testnet. There is no undo or rollback. The following command is a suggestion.

```
systemctl stop lynx && rm -rf ~/.lynx/testnet3/*
```

### Step 2: Prepare the primary creation daemon

*Determine which VPS will initialize the network with the first 1500 blocks.*

As of 2024, Lynx is a Proof of Stake project, but the initialization of the first 1500 blocks of the network is completed with Proof of Work. The process requires a single node to start the process. Keep all other nodes off or disconnected from the network. Again, if any of them are enabled, you will lose your work as the peer will have a longer chain. Your primary daemon will have its blockchain history reset to the peer's longer chain history.

{% hint style="info" %}
Not turning off all peer nodes or enabling a peer node without deleting its chain history is the primary reason this process fails. There is no harm in starting over again, but go slow and stay disciplined in your process.
{% endhint %}

### Step 3: Set your startup parameters

*Configure two temporary upstart arguments.*

When Lynx starts, the daemon discovers no peers and assumes the chain state is stale because no blockchain history is known. The daemon will find itself 'stuck,' and nothing will happen. To prevent this, force the two following start-up parameters on the daemon.

<pre><code><strong>/usr/local/bin/lynxd -maxtipage=9999999999 -stakethreadignorepeers=1
</strong></code></pre>

Fundamentally, you are telling the daemon to ignore the fact that the stale state of the network can be ignored and to ignore the PoW or PoS mining status of any other peer (during this sensitive period) discovered. You will remove these two parameters later.

### Step 4: Start one daemon and create reward addresses

*Create addresses to capture the new block rewards.*

Start the daemon and review the debug log. Be sure to review the debug log for the respective network you are working on; the testnet has its own debug log here.

```
~/.lynx/testnet3/debug.log
```

{% hint style="warning" %}
This guide does not cover the intricacies of updating your genesis block consensus parameters. This documentation assumes you have set 'testnet=1' in your lynx.conf file.
{% endhint %}

To start creating blocks, you must have addresses known to the daemon to collect the coinbase reward. Be sure to configure your lynx.conf file with the network parameter to indicate which network you are operating. Execute the following command five times to create unique addresses on the node.

```
lynx-cli getnewaddress
```

Save these addresses; you will need them in the next step.

### Step 5: Create Proof of Work blocks

*Capture the coinbase rewards from the first blocks created.*

Using the RPC command 'generatetoaddress', you will force the creation of blocks in sets. The following example creates five blocks and assigns the coinbase reward to the respective address. This is one of the addresses generated in the previous step. Execute this step repeatedly for each address you create. A shell script or crontab is recommended to automate this process.

```
lynx-cli generatetoaddress 5 n1S1eMboLoSh1HHhN8SkcJuUFZFGvcH4tU
```

The trick is not to create the blocks too fast. Later, the Proof of Stake algorithm will use the time stamps of the created blocks to impact the target block time. If you create these new blocks too fast or in too large amounts, the PoS algorithm may become stuck later. An example of a crontab script is below.

```
* * * * * /usr/local/bin/lynx-cli generatetoaddress 5 n1S1eMboLoSh1HHhN8SkcJuUFZFGvcH4tU
* * * * * /usr/local/bin/lynx-cli generatetoaddress 5 mmEa2dxWboBULTrkxusSqa9FhBKvpTLkxr
* * * * * /usr/local/bin/lynx-cli generatetoaddress 5 mmXDnnLpg52aM7mWEJzBHmz3EAxWVoStEf
* * * * * /usr/local/bin/lynx-cli generatetoaddress 5 mnabyg7dU4HBafQwzGRRcobaFPnaqwojC9
* * * * * /usr/local/bin/lynx-cli generatetoaddress 5 mtoL1qGoFVs4ecKuWazBtPvcyeYuiUgvRM
```

### Step 6: Forcibly turn off staking

*Prevent simultaneous PoS and PoW block creation errors.*

After a while, you will see 'incorrect proof of work' entries in the debug log. This happens because the Lynx daemon starts the staking thread automatically. This is a feature, not a bug. During this block creation period, the debug log will generate a long list of these messages. You can avoid these by turning off staking using the following command.

```
lynx-cli setstaking false
```

Once block 1500 is reached, you can stop this process and proceed to the next step of using Proof of Stake to create blocks.

### Step 7: Allow your target block time to stabilize

*Be patient and allow the difficulty adjustment algorithm to work.*

Once your maximum PoW block has been reached, you can restart your primary Lynx daemon. You will know when no more PoW blocks get created. You should only restart this daemon, no others yet. You'll need to be patient at this step. If you are impatient and send Lynx coins to other nodes, you risk creating a stuck network, and then you would have to start the process over again.

{% hint style="info" %}
You can turn off your crontab of 'generatetoaddress' commands now. If you don't, you will notice that PoS blocks won't get created and the chain will appear stuck.
{% endhint %}

When you restart your daemon, you need to kickstart the staking for this sole daemon (remember, it has no peers). Use the following command to start your daemon node.

```
/usr/local/bin/lynxd -maxtipage=9999999999 -stakethreadignorepeers=1
```

The goal of this step is to let the node stake and wait for the block time to settle around the intended target time. Since Lynx has a 5-minute block time, you are waiting for the daemon to report this block time in the debug log consistently. The debug log contains a 'Block Statistics' report every 25 blocks. Wait for this report to appear in the debug log, and pay close attention to the 'last hour' section. In the case of Lynx, we are looking for a 300-second block time. Ideally, we should see several reports of this target block time. This process might take several hours - sometimes even a full 24 hours. Their is no rush, so waiting 24 hours is fine.

You can provision other daemons during this time and let them sync to your primary node. However, ensure you have deleted the blockchain history before you start the daemon. Sometimes, it's best to double-check for safety. If you don't, the nodes will sync, and the primary node will lose its history - overwritten by the longer blockchain history on the peer node. You will have to restart the process completely if this occurs.

{% hint style="warning" %}
Don't send any coins to other peers yet. You need to ensure the network block time has settled.
{% endhint %}

### Step 8: Cleanup and Peer Staking

*Send coins to peers so they can stake and stabilize the network.*

By this time, you have provisioned other nodes, they have synced with your primary node, and your block time has settled to a relatively stable 300-second period. Those other nodes don't have any coins yet; this is good. Now, remove the startup parameters (-maxtipage=9999999999 -stakethreadignorepeers=1) on the primary node and restart Lynx. This will allow other nodes to start staking gracefully after they receive coins.

After a while, sending a small number of coins to peer nodes will be safe. The maturity time is 30 blocks, so keep this in mind when sending coins. You must start small so the primary staking node doesn't get stuck.

{% hint style="info" %}
Sending too many coins too early will cause the node to get stuck. The reason the primary staking node would get stuck is complicated but understandable. When you created the primary staking node, you only created a limited number of addresses for staking. The coinbase reward requires 30 blocks to maturity before sending the coins to another address. If you generate a send transaction with immature coins, the daemon will hold the transaction in the mempool and remain in that state for up to 24 hours. This could lock up coins in a state that will disallow them to be used for staking - thus, the node will 'get stuck.' With staking enabled, this is a known issue when using a hot wallet on a Lynx node. The recommendation is to keep two nodes. One has no send transactions while staking is enabled, and another hot wallet node has staking disabled.
{% endhint %}

### Step 9: Monitor your network

After you are able to see peer nodes win staking rewards and the distribution of staking effort becomes flattened across the network of nodes, you can consider your task complete.

***

### Video Tutorial

The video below is long, but for our visual learners, it can illustrate the 8 steps for a deeper understanding of how to execute the process.

{% embed url="<https://www.loom.com/share/eb947da601c24025bf1d14882e837018?sid=9ad0b456-aab3-4388-9fc1-052cc6bc8090>" %}


# Public Peer Nodes

Published: December 2024 | Last updated: April 2025

Our blockchain network maintains a set of public peer nodes that serve as reliable entry points for network participation. These well-known nodes are preconfigured directly in the software's source code, meaning that in most cases, you won't need to manually add them to your configuration file. The software automatically establishes connections with these trusted peers when you start your node.

For advanced users who wish to customize their peer connections or need to reference the default nodes, these nodes are configured using the 'addnode' parameter in the configuration file. Our development team manages and maintains these nodes, ensuring they remain stable and continuously synchronized with the latest blockchain state.

### Configuration Details

While manual configuration is typically unnecessary due to the built-in node addresses, you may want to know the addresses of our public peers for reference or troubleshooting. [Our network maintains five public nodes](http://status.getlynx.io/) for redundancy and optimal network distribution. A connection to at least three nodes ensures reliable network participation. Here are the addresses of our public peers:

{% code title="\~/.lynx/lynx.conf" %}

```
addnode=node1.getlynx.io
addnode=node2.getlynx.io
addnode=node3.getlynx.io
addnode=node4.getlynx.io
addnode=node5.getlynx.io
```

{% endcode %}

### Node Management

Our development team [actively monitors these public nodes](http://status.getlynx.io/) to maintain their reliability. We regularly:

* Update node software to the latest stable version
* Monitor network connectivity and performance
* Ensure high uptime and availability
* Verify blockchain synchronization status

This ongoing maintenance helps ensure that new nodes can reliably join the network and existing nodes can maintain robust peer connections. The automatic inclusion of these peer addresses in the software simplifies the setup process for most users while maintaining the flexibility needed for advanced configurations.


# Understanding Blockchain Bootstrap Files

Published: April 2024 | Last updated: February 2025

### Introduction

When someone wants to participate in the Lynx network by running a full node, they face an initial challenge: downloading and verifying the entire blockchain history, which can take several hours with a fast internet connection. A bootstrap file offers a solution to this challenge, serving as a compressed snapshot of the blockchain's transaction history. This document explores what bootstrap files are, how to use them, why they matter, and how they benefit the cryptocurrency ecosystem.

### What is a Bootstrap File?

A bootstrap file (typically named bootstrap.dat) is fundamentally a snapshot of validated blockchain history. Think of it like a digital time capsule containing every transaction that has ever occurred on the network up to a specific point. Just as a library might keep archived copies of newspapers to preserve history, a bootstrap file preserves blockchain history in a format optimized for quick import and verification.

The file contains all the essential components of the blockchain:

* Complete blocks with their transaction data
* Timestamps marking when each block was created
* Proof-of-work & Proof-of-stake solutions validating each block
* Cryptographic links that maintain the chain's integrity

### Technical Implementation and Usage Guide

The bootstrap file serves as an efficient way to transfer blockchain data while maintaining cryptographic security. During the import process, your node performs all the standard verification checks, just as it would during network synchronization. The key advantage comes from reading this data directly from your local storage rather than downloading it block by block over the network.

However, it's crucial to understand that simply placing the bootstrap.dat file in the .lynx directory is not sufficient. The node requires specific instructions to process this file. Here's the correct procedure:

1. First, obtain and place your bootstrap.dat file in an accessible location on your system.
2. To initiate the import process, you must explicitly tell the lynx daemon to load the bootstrap file using the 'loadblock' parameter. The command follows this format:

```
lynxd -loadblock=/root/.lynx/bootstrap.dat
```

3. Wait for the daemon to complete processing the bootstrap file. You can monitor progress in the debug log. Your debug log will display an 'Importing blocks file' line indicating the file is being indexed.&#x20;

<figure><img src="/files/CuKruP1OMWMg2WtURSgs" alt=""><figcaption><p>The Lynx debug log showing the bootstrap import has begun.</p></figcaption></figure>

3. Once the import is complete (and this will take a while), restart the daemon normally without the 'loadblock' parameter to resume standard operation.&#x20;

Important Note: The daemon won't automatically detect and import the bootstrap.dat file even if it's placed in the \~/.lynx directory. You must use the 'loadblock' parameter to trigger the import process. This requirement ensures deliberate and controlled blockchain data importing.

This process combines the reliability of full verification with the efficiency of bulk data transfer, making it particularly valuable for deploying multiple nodes or managing large-scale node operations.

### Why should bootstrap.dat be used?

#### Resource Management

While bootstrap.dat doesn't significantly reduce the total processing time compared to network synchronization via Initial Block Download (IBD), it offers important benefits for bandwidth management. The primary advantage is the reduction in network traffic, making it particularly valuable in environments with limited or metered internet connections. For single daemon installations, the overall import time remains comparable to network synchronization, as the node still needs to process and validate each block.

#### Performance Optimization

The most significant performance gains come from combining bootstrap.dat with the assumevalid parameter, though it's important to understand how the daemon handles these optimizations in different scenarios.

When you launch the daemon with both features:

```bash
lynxd -loadblock=/root/.lynx/bootstrap.dat -assumevalid=890dfec78ea384f7c0ac421dd805bd8a39b8c36ae581efb64cec151fc6ced2e8
```

The node first checks its existing block history. If the blockchain has already been fully synchronized, the daemon will intelligently ignore the loadblock parameter. This behavior prevents unnecessary reprocessing of data you already have, much like how a library wouldn't re-catalog books that are already in its system.

However, for fresh installations or nodes that need to catch up, the optimization process works in two complementary ways. First, the node reads blockchain data efficiently from your local storage using the bootstrap file. Second, it skips the computationally intensive process of cryptographic signature verification for the first 3 million blocks, as specified by the assumevalid parameter. Your node will still perform full script validation for all blocks after height 3,000,000, ensuring you maintain strong security for more recent history while gaining significant performance benefits for older blocks.

Think of this process as similar to reading a lengthy historical document. The first three million pages (blocks) have been authenticated by trusted historians (assumevalid), so you can quickly review their content without verifying each author's signature. However, for the more recent chapters, you perform a thorough verification process, ensuring the highest level of scrutiny where it matters most.

The assumevalid hash represents a known-valid block [at height 3,000,000](https://chainz.cryptoid.info/lynx/block.dws?890dfec78ea384f7c0ac421dd805bd8a39b8c36ae581efb64cec151fc6ced2e8.htm) that has been thoroughly verified by the development team. Using this parameter is not just safe but recommended, as it can reduce synchronization time from hours to minutes while maintaining the security of your node. When combined with bootstrap.dat, you get the best of both worlds: efficient data transfer and rapid processing, while still performing full validation on the most recent portion of the blockchain where it matters most.

This intelligent combination of features—the selective use of bootstrap.dat based on existing data and the targeted application of assumevalid—makes the synchronization process both efficient and secure, optimizing system resources while maintaining the integrity of your node.

#### Network Consideration

Bootstrap files become particularly valuable when deploying multiple nodes simultaneously, such as in staking farms or node arrays. In these scenarios, downloading the blockchain once and distributing it locally via bootstrap.dat files can dramatically reduce external network traffic. Instead of having each node independently download the full blockchain—which could saturate network connections and create significant bandwidth costs—operators can efficiently replicate the blockchain data across their infrastructure. This approach is especially beneficial for large-scale operations where dozens or hundreds of nodes need to be synchronized, making bandwidth management and network resource optimization critical considerations.

#### Use Cases and Beneficiaries

**Developers and Businesses**

For those building on blockchain technology, time is a critical resource. Bootstrap files enable:

* Rapid deployment of environments with reduced network chatter
* Efficient scaling of node infrastructure

**System Administrators**

System administrators responsible for maintaining cryptocurrency infrastructure benefit from:

* Faster disaster recovery
* Simplified node deployment
* Reduced network resource consumption
* More predictable setup times

**Researchers and Analysts**

Those studying blockchain data find value through:

* Immediate access to historical data
* Consistent dataset availability
* Reduced setup time for analysis environments
* Reliable access to specific blockchain states

### Trust and Security Considerations

While bootstrap files offer significant advantages, they introduce an element of trust. Users must have confidence in the source of their bootstrap file, as they're accepting the validity of the entire chain up to that point. This trust is typically established through:

* Cryptographic checksums verifying file integrity
* Distribution by reputable entities
* Community verification of contained data
* Transparent creation processes

{% hint style="success" %}
The Lynx Core Development team maintains official bootstrap files on the Lynx GitHub repository. For security and reliability, you should always obtain Lynx bootstrap files from this official source. Both current and historical bootstrap files are available in the repository, ensuring you can access the specific blockchain data you need. Visit the [Lynx GitHub repository to download](https://github.com/getlynx/LynxBootstrap/releases) these verified bootstrap files.
{% endhint %}

### Conclusion

Bootstrap files represent a practical solution to the challenge of blockchain synchronization. They embody a balance between trust, efficiency, and security while providing tangible benefits to various stakeholders in the cryptocurrency ecosystem. As blockchain technology continues to evolve, bootstrap files and similar tools will likely play an increasingly important role in maintaining the health and accessibility of these networks.


# Bootstrap Extraction Script

Published: January 2025 | Last updated: February 2026

## Understanding the Lynx Bootstrap Extraction Script

When you first set up a Lynx node, synchronizing with the blockchain can take considerable time. This bootstrap extraction script provides a solution by automating the download and installation of pre-validated blockchain data, significantly reducing the time needed to get your node running.

### The Purpose of Bootstrapping

Blockchain synchronization typically requires downloading and validating every transaction since the network's inception. This process can take several hours depending on your system and network connection. The bootstrap process offers a shortcut by providing a verified snapshot of the blockchain up to a recent point, leaving your node to sync only the most recent blocks.

### Execution of the Script

To download and install a complete bootstrap to a Lynx node, download and execute this script:

```bash
wget -O - https://raw.githubusercontent.com/getlynx/LynxBootstrap/master/extract.sh | bash
```

### Understanding How the Script Works

The script follows a careful, methodical process to ensure your blockchain data is downloaded and verified correctly:

#### Initial Setup Phase

The script begins by checking your system's readiness. It verifies the Lynx installation, ensures all required directories exist, and confirms it has the necessary permissions to operate. This prevents potential issues before any downloads begin.

#### Cleanup Operations

Before downloading new bootstrap data, the script removes any remnants of previous bootstrap attempts. This prevents conflicts and ensures you're starting with a clean slate. The cleanup process is also intelligent enough to handle files in different locations and with various naming patterns.

#### Download and Verification Process

The script downloads bootstrap data in chunks, making the process more manageable and resilient. If the script fails halfway, you can run the script again and it will pick up where it left off. Each chunk goes through a rigorous verification process:

* The script first downloads a manifest file containing checksums
* For each chunk, it verifies the SHA256 checksum matches the manifest
* If verification fails, the script automatically attempts to redownload the chunk
* Only after all chunks are verified does the script proceed to installation

#### Installation and Integration

The final phase combines the verified chunks and integrates them with your Lynx installation. The script:

* Combines all chunks into a single bootstrap file
* Extracts the data to your Lynx directory
* Performs a final cleanup to remove temporary files

### Understanding Your Directory Structure

The script works with Lynx's standard directory structure:

```
$HOME/
└── .[daemon]/
    ├── blocks/      # Contains the actual blockchain data
    ├── chainstate/  # Contains the current state of the blockchain
    └── lynx.conf    # Your Lynx configuration file
```

The bootstrap.dat file will be placed in the $HOME/.lynx/ directory. [The final step is to restart your Lynx daemon and instruct it to use the bootstrap.dat file.](https://docs.getlynx.io/lynx-administration/bootstraps#technical-implementation-and-usage-guide)

### Contributing

Contributions are welcome! Please [feel free to submit a Pull Request.](https://github.com/getlynx/LynxBootstrap/pulls)

### Support

If you encounter any issues or need assistance, please:

1. Check the Common Issues section above
2. Create an issue in the GitHub repository
3. Visit the [Lynx Documentation](https://docs.getlynx.io) for more information
4. [Visit us on Discord](https://discord.gg/6jUaNeV2Uy)

### Acknowledgments

* Bitcoin Core's linearize scripts (which were adapted for Lynx)


# Bootstrap  Creation Script

Published: January 2025 | Last updated: February 2025

This script automates the process of creating a bootstrap archive for the Lynx blockchain. It generates a bootstrap.dat file from your local blockchain data and splits it into manageable chunks for easier distribution.

{% hint style="warning" %}
This is not the script to use if you are looking to download a bootstrap file to your Lynx node for faster sync. Instead, [use the extraction script](/lynx-administration/bootstraps/bootstrap-extraction-script).
{% endhint %}

### Overview

The script performs the following operations:

1. Locates your Lynx installation directory
2. Validates the environment and required tools
3. Creates a bootstrap.dat file from your local blockchain
4. Compresses and splits the bootstrap file into 125MB chunks
5. Generates a manifest file with SHA256 checksums for verification

### Requirements

* Lynx Core must be installed and fully synced
* Python (for the linearize scripts)
* 2GB of free disk space for the bootstrap file creation
* Staking should be disabled to avoid Python socket errors
* Write permissions in the Lynx home directory

### Installation

To construct a backup bundle from a fully synced Lynx node, download and execute this script:

```bash
wget -O - https://raw.githubusercontent.com/getlynx/LynxBootstrap/master/archive.sh | bash
```

### Output Files

The script generates the following files:

* `YYYY-MM-DD-bootstrap.tar.gz.*` - Compressed bootstrap chunks
* `YYYY-MM-DD-manifest.txt` - SHA256 checksums for verification

### Important Notes

* Keep both the chunk files and manifest.txt for proper reassembly
* The script expects the .lynx directory to be in its default location
* The process may take considerable time depending on blockchain size
* Ensure sufficient disk space is available before running

### Technical Details

* Chunks are created at 125MB size for easier transfer
* The script uses Python's linearize tools from the Lynx Core repository
* Block height is set to (current - 100) for safety
* RPC credentials are automatically extracted from lynx.conf

### Common Issues

1. **Permission Denied**: Ensure you have write access to the Lynx directory
2. **lynx-cli not found**: Make sure Lynx Core is properly installed and running
3. **Space Issues**: Ensure sufficient disk space for bootstrap creation

### Contributing

Contributions are welcome! Please [feel free to submit a Pull Request.](https://github.com/getlynx/LynxBootstrap/pulls)

### Support

If you encounter any issues or need assistance, please:

1. Check the Common Issues section above
2. Create an issue in the GitHub repository
3. Visit the [Lynx Documentation](https://docs.getlynx.io) for more information
4. [Visit us on Discord](https://discord.gg/6jUaNeV2Uy)

### Acknowledgments

* Bitcoin Core's linearize scripts (which were adapted for Lynx)


# Staking-Only Wallet Lock

Published: January 2026 | Last updated: February 2026

### Staking and Wallet Security

Lynx uses a Proof-of-Stake (PoS) consensus mechanism, which means users can help secure the network and earn rewards by staking their coins. This guide explains how to stake safely using the command line interface.

### Understanding Proof of Stake

In Proof of Stake, you "stake" your coins to validate transactions and secure the network. Your staking power is proportional to the number of coins you hold. When your wallet successfully validates a block, you earn staking rewards.

### Staking Requirements

To stake your coins and earn rewards, your wallet must be:

1. Synchronized - Fully synced with the respective blockchain
2. Online - Running and connected to the network 24/7 (or as much as possible)
3. Holding mature coins - Your coins must have at least 30 confirmations
4. Unlocked for staking - Your (optionally) encrypted wallet must be unlocked specifically for staking

### Encrypting Your Wallet

{% hint style="warning" %}
**CRITICAL: Always encrypt and backup your wallet before staking.**
{% endhint %}

Wallet encryption protects your private keys with a password. This is essential for staking wallets that must remain online continuously.

Create a strong passphrase:

* Use at least 12 characters
* Include uppercase, lowercase, numbers, and symbols
* Example: `7hG!xPq2@nM9wLz4#vK8`

Encrypt your wallet:

```bash
[daemon]-cli encryptwallet "your-strong-passphrase-here"
```

**Example for Lynx:** lynx-cli encryptwallet "your-strong-passphrase-here"

{% hint style="danger" %}
**WARNING: If you lose your passphrase, you will permanently lose access to your coins.**
{% endhint %}

### Unlocking for Staking Only

The key security feature is the ability to unlock *for staking only*. This allows your wallet to stake while preventing unauthorized transactions.

#### Staking-Only vs Full Unlock

* Staking-Only Unlock: Wallet can stake and earn rewards, but CANNOT send coins
* Full Unlock: Wallet can stake AND send transactions (use only when you need to send coins)

### Unlock Commands

Unlock for staking only (recommended):

```bash
[daemon]-cli walletpassphrase "your-strong-passphrase-here" 0 true
```

**Example for Lynx:** lynx-cli walletpassphrase "your-strong-passphrase-here" 0 true

Unlock fully for 5 minutes (only when sending coins):

```bash
[daemon]-cli walletpassphrase "your-strong-passphrase-here" 300 false
```

**Example for Lynx:** lynx-cli walletpassphrase "your-strong-passphrase-here" 300 false

Parameters explained:

* `"your-passphrase"` - Your wallet encryption password (in quotes)
* `0` - Timeout in seconds (0 = indefinite, or use specific seconds like `600` for 10 minutes)
* `true` - Staking-only mode / `false` - Full unlock

### Lock Your Wallet

When you need to lock your wallet (for security or before sending coins):

```bash
lynx-cli walletlock
```

After locking, unlock again for staking:

```bash
lynx-cli walletpassphrase "your-strong-passphrase-here" 0 true
```

### Protecting Your Passphrase in Command History

{% hint style="info" %}
When you unlock your wallet, your passphrase is saved in your terminal history. You should clear it.
{% endhint %}

#### Recommended Method

Remove last command from history:

```bash
history -d $((HISTCMD-1))
```

Remove complete command from history:

```bash
history -c
```

Temporarily disable history:

```bash
set +o history
lynx-cli walletpassphrase "your-strong-passphrase-here" 0 true
set -o history
```


# Migrating Legacy InfiniLoop Coins

Published: July 2026 | Last updated: July 2026

With [Lynx Core v27.1.0](https://github.com/getlynx/Lynx/releases/tag/v27.1.0), InfiniLoop joined the Lynx storage network as the eleventh chain brought online via the blockchain recycling strategy. The entire legacy InfiniLoop transaction history is preserved on the new network, which means coins held on the legacy chain carry over — you just need to move your keys from the old wallet software into the new one.

The process takes about ten minutes of hands-on time, plus however long the new node takes to sync.

> ### ⚠️ Follow These Steps in Order — This Matters
>
> **Do not import your keys or enable staking until the new node has fully synced.** The order of the steps below is not a suggestion.
>
> If you import your wallet and restart with staking enabled before the sync is finished, your node will attempt to stake against a chain it hasn't caught up on. This behaves badly on the network and **can get your IP address banned from the legacy InfiniLoop network for 24 hours** — leaving you unable to complete the sync from that machine until the ban expires (or until you resume from a different IP address).
>
> Let the node finish syncing first (Step 5). Only then import your keys (Step 6) and re-enable staking (Step 7). Doing it in this order avoids the problem entirely.

### Before You Begin

* You'll need access to your legacy InfiniLoop wallet (the old software, with your coins in it)
* You'll need a machine to run the new InfiniLoop node — the [Spark installer](https://github.com/getlynx/Lynx/tree/main/contrib/installer) supports the same platforms as the rest of the Lynx network
* Set aside time for the new node to download and verify the blockchain before your keys can be imported

### Step 1 — Export Your Keys from the Old Wallet

With your legacy InfiniLoop node running, open a terminal on the same machine.

{% tabs %}
{% tab title="Unencrypted Wallet (default)" %}
Now export your keys:

```
infiniloop-cli dumpwallet /root/keys.txt
```

{% endtab %}

{% tab title="Encrypted Wallet" %}
**If your wallet is encrypted:** you must unlock it before it will let you export your keys. Run the following, replacing `<pp>` with your wallet passphrase:

```
infiniloop-cli walletpassphrase "<pp>" 3600
```

The `3600` is how many seconds the wallet stays unlocked (one hour) — plenty of time to finish the export. For example, if your passphrase is `flurb`, you would run:

```
infiniloop-cli walletpassphrase "flurb" 3600
```

Now export your keys:

```
infiniloop-cli dumpwallet /root/keys.txt
```

{% endtab %}
{% endtabs %}

This writes all of your private keys to a plain text file.

⚠️ **Treat this file like cash.** Anyone who gets a copy of it can take your coins. Keep it on the local machine only, never email or upload it, and delete it once the migration is complete.

### Step 2 — Shut Down the Legacy Wallet

Stop the old InfiniLoop software completely before continuing.

### Step 3 — Make a Safety Copy of Your Old Wallet File

Copy the `wallet.dat` file from your legacy InfiniLoop data directory to a safe location:

```
cp ~/.infiniloop/wallet.dat /root/
```

You shouldn't need it again, but keep it until you've confirmed your balance on the new network.

### Step 4 — Install and Start the New InfiniLoop Node

Use the [Spark installer](https://github.com/getlynx/Lynx/tree/main/contrib/installer) with a fresh data directory. Before starting the node, **disable staking** by adding this line to your configuration file:

```
disablestaking=1
```

Then start the node.

### Step 5 — Let the Node Fully Sync

The node needs to download and verify the entire blockchain before your keys can be imported. This can take a while. You can check progress with:

```
infiniloop-cli getblockchaininfo
```

You're ready to continue when the block height growth rate transitions from no time between blocks to approximately 5 minutes between blocks.

⚠️ **Do not proceed to Step 6 until you see this.** Importing your keys and enabling staking before the sync completes is exactly what triggers the network ban described at the top of this guide. Be patient here — this is the single most important step to get right.

### Step 6 — Import Your Keys

**First, confirm the node is fully synced** (see Step 5). Only continue once the block rate has settled to roughly one block every 5 minutes.

Once fully synced, run:

```
infiniloop-cli importwallet /root/keys.txt
```

The node will scan the chain for your transactions. When it finishes, your balance should appear.

### Step 7 — Turn Staking Back On

Set the `disablestaking=1` line from your configuration file to `disablestaking=0` and restart the node. Your migrated coins are now staking on the new network.

### Cleaning Up

Once you've confirmed your full balance on the new network:

* Delete the exported key file: `rm /root/keys.txt`
* You may keep or delete the backup `wallet.dat` copy at your discretion — if you keep it, store it somewhere secure

### Need Help?

If you run into any trouble along the way, reach out to the development team on the **Lynx Discord** and we'll walk you through it. For more on the blockchain recycling strategy and the InfiniLoop transition, visit <https://docs.getlynx.io/>.


# Raspberry Pi: Complete Setup and Management Guide

Published: July 2025 | Last updated: Febraury 2026

### Overview

The Lynx Raspberry Pi ISO is a slightly modified version of the Raspberry Pi Foundation release of [Raspberry Pi OS](https://www.raspberrypi.com/software/operating-systems/) designed to automatically set up and manage a Lynx cryptocurrency node on Raspberry Pi devices. This pre-configured image eliminates the complexity of manual node setup by providing a plug-and-play solution that handles everything from initial system configuration to ongoing blockchain synchronization.

### What Makes This ISO Special

#### Automated Node Deployment

The custom ISO transforms a standard Raspberry Pi OS Lite 64-bit ARM image into a specialized Lynx node environment. Upon first boot, the system automatically:

* Downloads and installs the latest Lynx ARM binaries
* Configures system services for optimal node operation
* Sets up memory management with appropriate swap configuration
* Establishes automated maintenance routines
* Provides an intuitive command-line interface for node management

#### Built-in Intelligence

The system includes sophisticated monitoring and maintenance capabilities:

* **Self-healing**: Automatically restarts services if they fail
* **Resource optimization**: Manages memory and swap to prevent crashes
* **Sync monitoring**: Tracks blockchain synchronization progress
* **Network resilience**: Handles network connectivity issues gracefully
* **Update management**: Maintains system components automatically

### System Requirements

#### Hardware Requirements

* **Raspberry Pi 4** (4GB RAM minimum, 8GB recommended)
* **MicroSD Card**: 32GB minimum (64GB+ recommended for long-term operation)
* **Network Connection**: Ethernet cable or WiFi capability
* **Power Supply**: Official Raspberry Pi 4 power adapter (5V/3A USB-C)

#### Network Requirements

* Stable internet connection for initial setup and blockchain synchronization
* Port 22566 available for P2P networking (default Lynx port)
* Outbound HTTPS access for updates and downloads

### Flashing the SD Card

#### Required Software

Download and install one of these SD card flashing tools:

* **Raspberry Pi Imager** - Available at [rpi.org](https://www.raspberrypi.org/software/)

#### Step-by-Step Flashing Process

**Using Raspberry Pi Imager**

1. **Download the Lynx ISO**
   * Obtain the latest `YYYY-MM-DD-Lynx-RPI-ISO.img.xz` file from the [official Lynx releases](https://github.com/getlynx/Lynx/releases)
   * Save it to your computer in an easily accessible location
2. **Prepare Your SD Card**
   * Insert a 32GB+ microSD card into your computer's card reader
   * Ensure the card is empty or that you're comfortable losing all existing data
3. **Flash the Image**
   * Launch Raspberry Pi Imager
   * Click "Choose OS" → "Use custom" and select your downloaded `.img.xz` file
   * Select your SD card from the storage options
   * Under Settings, be sure to enter your WiFi credentials and default username and password. This is required if you plan to log into your Pi later and enable staking.

     <figure><img src="/files/9eCa9zO5lvFNBE3TxoKa" alt=""><figcaption></figcaption></figure>
   * Click "Write" and wait for the process to complete (typically 1-3 minutes)
4. **Verify the Flash**
   * The imager will automatically verify the write process
   * Safely eject the SD card when prompted

### First Boot Process

#### What Happens Automatically

When you insert the SD card and power on your Raspberry Pi, the following sequence occurs automatically:

**Phase 1: System Initialization (0-60 seconds)**

* Standard Raspberry Pi OS boot process
* Network interface configuration
* System service startup
* IP address assignment display

**Phase 2: Network Preparation (60-90 seconds)**

* 60-second waiting period for network stabilization
* Network connectivity testing (ping to 8.8.8.8)
* If network fails: automatic reboot and retry

**Phase 3: Lynx Installation (90 seconds - 5 minutes)**

* Download of the [latest builder script](https://github.com/getlynx/Lynx/blob/main/contrib/pi/builder.sh) from GitHub
* System optimization (swap configuration)
* Lynx binary download and installation
* Service configuration and startup

**Phase 4: Node Initialization (5+ minutes)**

* Lynx daemon startup
* Blockchain synchronization begins
* Automated monitoring system activation
* User interface setup completion

#### Monitoring First Boot

You can monitor the progress, as root, by connecting a monitor and keyboard, or via SSH:

**Via Monitor:**

* Connect HDMI monitor and USB keyboard
* Watch the console output for progress updates
* IP address will be displayed early in the boot process

**Via SSH:**

* Use the displayed IP address to connect: `ssh [username]@[IP_ADDRESS]`
* Be sure to run `sudo su` - you must be root to interact with the system
* Default credentials you entered with Pi Imager
* Monitor logs: `jou`

### Understanding the Custom ISO Components

#### Automated Setup Script (rc.local)

The ISO includes a custom `/etc/rc.local` file that:

* Displays network information
* Implements intelligent network waiting
* Downloads the latest node software
* Handles network failure scenarios gracefully
* Self-disables after successful setup

#### Builder Script Functionality

The main builder script (`builder.sh`) provides:

* **System Optimization**: Automatic swap file management
* **Binary Management**: Downloads and installs Lynx binaries
* **Service Management**: Creates and manages systemd services
* **Monitoring**: Tracks synchronization and system health
* **User Experience**: Sets up command aliases and help system

#### Systemd Services Created

The system creates several services for optimal operation:

**lynx.service**: Main Lynx daemon service

* Automatically starts the Lynx node
* Handles graceful shutdowns
* Includes restart policies for reliability

**builder.service & builder.timer**: Maintenance system

* Runs every 12 minutes during initial sync
* Monitors blockchain synchronization progress
* Self-disables once sync is complete
* Provides ongoing system health checks

### Node Management Interface

Once your Lynx node is running, you'll have access to a comprehensive command-line interface designed for both beginners and advanced users.

#### Accessing the Management Interface

**Local Access:**

* Connect monitor and keyboard to your Raspberry Pi
* Log in with default credentials (example username: `pi`, password: `raspberry`)
* The help interface appears automatically after running `sudo su` to switch to the root account

**Remote Access via SSH:**

```bash
ssh pi@[YOUR_PI_IP_ADDRESS]
```

#### Command Categories

**Wallet Management Commands**

**`gba` - Get Wallet Balances**

```bash
gba
```

Displays all wallet balances including confirmed, unconfirmed, and staking balances. Essential for monitoring your node's financial status.

**`gna` - Generate New Address**

```bash
gna
```

Creates a new receiving address for your wallet. Use this when you need to receive Lynx coins.

**`lag` - List Address Groupings**

```bash
lag
```

Shows how addresses are grouped in your wallet, helpful for understanding coin organization and privacy.

**`sta` - Send to Address**

```bash
sta [address] [amount]
```

Sends Lynx coins to a specified address. Example:

```bash
sta KLynxAddress123... 10.5
```

**`swe` - Sweep Wallet**

```bash
swe [address]
```

Sends all available funds to an address, useful for wallet consolidation or moving funds.

**System Monitoring Commands**

**`lyv` - Show Lynx Version**

```bash
lyv
```

Displays the current Lynx daemon version and build information.

**`gbi` - Get Blockchain Info**

```bash
gbi
```

Shows comprehensive blockchain synchronization status including:

* Current block height
* Sync progress percentage
* Network difficulty
* Verification progress

**`lss` - Service Status**

```bash
lss
```

Displays the current status of the Lynx systemd service, including whether it's running, any recent errors, and resource usage.

**`jou` - View System Logs**

```bash
jou [lines] [-f]
```

Shows real-time builder script logs, essential for troubleshooting and monitoring system health.

**Configuration and Maintenance**

**`lyc` - Edit Configuration**

```bash
 lyc [-e] 
```

Opens the Lynx configuration file in nano editor for advanced users who need to modify node settings.

**`lyl` - View Debug Logs**

```bash
 lyl [lines] [-f]
```

Displays real-time Lynx daemon debug logs, crucial for troubleshooting blockchain synchronization issues.

**`lyr` - Restart Node**

```bash
lyr
```

Safely stops and restarts the Lynx daemon, clearing debug logs in the process. Use when the node appears stuck or unresponsive.

**`h` - Show Lynx Help**

```bash
h
```

Displays comprehensive help for all available Lynx CLI commands.

**Utility Commands**

**`htop` - System Monitor**

```bash
htop
```

Interactive system resource monitor showing CPU, memory, and process information.

**`motd` - Show Help Interface**

```bash
motd
```

Redisplays the complete command help interface with current staking statistics.

#### Understanding the Help Interface

The system displays an ASCII art interface showing:

**Node Statistics**

* **Stakes Won**: Number of proof-of-stake blocks found in the last 24 hours
* **Real-time Updates**: Statistics update each time you run `motd`

**Command Categories**

Commands are organized into logical groups:

* **Wallet Commands**: For managing coins and addresses
* **System Commands**: For node operation and troubleshooting
* **Useful Commands**: For system monitoring and help

**Resource Links**

Direct links to:

* Complete project documentation
* Permanent file storage solutions
* Blockchain explorer
* Trading platforms

### Blockchain Synchronization Process

#### Understanding Sync Phases

**Initial Block Download**

* Downloads the entire blockchain from network peers
* Can take 2-24 hours depending on network speed (typically 4 hours with average broadband speeds)
* Progress visible via `gbi` command
* System automatically optimizes during this phase

**Verification Phase**

* Validates downloaded blocks
* Ensures blockchain integrity
* May restart daemon periodically for optimization (normal behavior, do not interrupt)
* Normal behavior during initial setup

**Maintenance Mode**

* Activated once sync is complete
* Minimal resource usage
* Automatic monitoring disabled
* Node ready for staking and transactions

#### Monitoring Sync Progress

**Check Sync Status:**

```bash
gbi
```

Look for these key indicators:

* `"initialblockdownload": false` - Sync complete
* `"verificationprogress": 1.0` - Verification complete
* `"blocks"` vs `"headers"` - Should be equal when synced

**Monitor Resource Usage:**

```bash
htop
```

During sync:

* CPU usage will be moderate to high
* CPU usage will be <1% when sync is complete
* Memory usage should remain stable
* Disk I/O will be active

**View Sync Logs:**

```bash
lyl
```

Watch for:

* Block download progress
* Peer connections
* Any error messages

#### Troubleshooting Sync Issues

**Node Appears Stuck:**

```bash
lynx  # Restart the daemon
```

**Check Network Connectivity:**

```bash
ping 8.8.8.8
```

**Verify Service Status:**

```bash
lss
```

**Review System Logs:**

```bash
jou
```

### System Maintenance and Updates

#### Automatic Maintenance Features

The system includes sophisticated automatic maintenance:

**Resource Management**

* Automatic swap file creation and management
* Memory optimization during blockchain sync
* Disk space monitoring and cleanup

**Service Management**

* Automatic daemon restarts during sync phase
* Health monitoring and recovery
* Log rotation and cleanup

**Update Management**

* Binary updates (manual process recommended)
* System package updates (standard apt process)
* Reflashing the SD card is recommended after a wallet sweep.

{% hint style="danger" %}
After sweeping a wallet, verify that coins are received at the remote address for safety. If staking was enabled, the movement of immature coins can delay the transaction. Only when coins are received, should you re-image the SD card.
{% endhint %}

#### Manual Maintenance Tasks

**Check System Health:**

```bash
lss           # Service status
htop          # Resource usage
jou           # Recent system logs
```

**Update System Packages:**

```bash
sudo apt update && sudo apt upgrade -y
```

**Monitor Disk Space:**

```bash
df -h         # Check available space
```

**Backup Wallet:**

```bash
# Copy wallet.dat to external storage
cp ~/.lynx/wallet.dat /path/to/backup/
```

### Security Considerations

#### Network Security

* Change default passwords immediately after first boot
* Enable SSH key authentication for remote access
* Consider firewall configuration for additional security
* Regularly monitor for unauthorized access attempts

#### Wallet Security

* **Backup Strategy**: Regular wallet.dat backups to multiple locations
* **Encryption**: Consider wallet encryption for added security
* **Access Control**: Limit physical and network access to the device
* **Updates**: Keep system and Lynx software updated

#### System Security

* **Regular Updates**: Apply system security updates promptly
* **Monitoring**: Review logs regularly for suspicious activity
* **Network**: Use secure networks and consider VPN for remote access

### Troubleshooting Common Issues

#### Node Won't Start

**Symptoms**: `lss` shows service as failed&#x20;

**Solutions**:

1. Check system resources: `htop`
2. Review error logs: `jou`
3. Restart service: `lyr`
4. Check disk space: `df -h`

#### Slow Synchronization

**Symptoms**: Sync progress is very slow&#x20;

**Solutions**:

1. Check network speed and stability
2. Verify sufficient disk space
3. Monitor resource usage: `htop`
4. Consider restarting daemon: `lyr`

#### Cannot Connect Remotely

**Symptoms**: SSH connection fails&#x20;

**Solutions**:

1. Verify Pi is powered on and booted
2. Check network connectivity
3. Confirm IP address hasn't changed
4. Verify SSH is enabled

#### Command Not Found Errors

**Symptoms**: Custom aliases don't work&#x20;

**Solutions**:

1. Re-login to reload bashrc
2. Manually run: `source ~/.bashrc`
3. Check if setup completed: `h`

### Wallet Issues

**Symptoms**: Cannot access wallet functions&#x20;

**Solutions**:

1. Verify daemon is running: `lss`
2. Check RPC credentials in config: `lyc`
3. Review debug logs: `lyl`
4. Restart daemon: `lyr`

### Getting Help and Support

#### Documentation Resources

* **Complete Documentation**: <https://docs.getlynx.io/>
* **API Reference**: Available through `h` command
* **Blockchain Explorer**: <https://chainz.cryptoid.info/lynx/>

#### Community Support

* **Trading Platform**: <https://freixlite.com/market/LYNX/LTC>
* **File Storage**: <https://clevver.org/>
* **GitHub Repository**: Source code and issue tracking

#### System Information Commands

When seeking help, these commands provide useful diagnostic information:

```bash
h             # Show current system status
lss           # Service status
gbi           # Blockchain sync status
jou           # Recent system logs
lyl           # Lynx daemon logs
htop          # Resource usage
```

### Conclusion

The Lynx Raspberry Pi ISO provides a complete, automated solution for running a Lynx cryptocurrency node. From initial flashing to ongoing management, the system handles complex tasks automatically while providing powerful tools for advanced users. The intuitive command interface makes node management accessible to users of all technical levels, while the robust automation ensures reliable operation with minimal intervention.

By following this guide, you'll have a fully functional Lynx node contributing to the network's security and decentralization while potentially earning staking rewards. The system's self-maintaining design means you can focus on using and enjoying your Lynx node rather than managing its technical complexities.


# Revolutionizing Digital Preservation

Permanent Digital Storage Through Blockchain Technology

![The above image is stored in Clevver - like all images on this website!](https://get.clevver.org/2e0cb655b8019757fe288d6d9509e78bdf510b3517c82f8941f3e772ed0b0fcb.png)

Clevver represents a breakthrough in digital preservation technology, offering a sophisticated platform that harnesses the Lynx blockchain for permanent data storage. Through its intuitive web interface and robust API, Clevver provides enterprise-grade permanence with consumer-grade simplicity. The platform's streamlined interface makes permanent digital storage as accessible as common web applications, while its underlying technology ensures unparalleled data permanence.

### Technical Architecture

The foundation of Clevver's capability lies in the Lynx blockchain's innovative architecture, which provides 500GB of data storage capacity per year per implementation. This capacity scales exponentially through project cloning, creating a sustainable growth model for long-term preservation needs. Clevver's implementation stores complete digital files directly on the blockchain—not merely references or hashes—generating permanent, immutable URLs that remain accessible throughout the blockchain's existence.

### Primary Applications

#### Digital Asset Preservation

Clevver provides comprehensive solutions for preserving digital assets, ensuring permanent linkage between NFTs and their associated content, maintaining personal media archives, and securing historical documentation. This permanent storage guarantees the integrity and accessibility of digital heritage across generations.

#### Journalistic Documentation

In the realm of media preservation, Clevver offers crucial capabilities for maintaining journalistic integrity. The platform ensures news articles and media content remain in their original form, protected from unauthorized modification or deletion, thereby maintaining an accurate historical record for future reference.

### Technical Advantages

Clevver's architecture fundamentally differs from traditional storage solutions such as IPFS, cloud storage, or server-based archives. By integrating digital content directly into the Lynx blockchain, Clevver eliminates common dependencies that typically require ongoing maintenance, regular payments, or institutional support. This integration provides:

* Single-instance upload without recurring costs
* Zero-maintenance architecture
* Global accessibility infrastructure
* Immutable data permanence

### Implementation Impact

Clevver addresses the fundamental challenges of digital preservation by transforming how organizations and individuals approach long-term storage of valuable digital content. The platform's implementation of blockchain technology creates a reliable, accessible, and maintenance-free solution for preserving digital assets, from NFT artwork to historical documentation.

***

Experience enterprise-grade permanent storage at [clevver.org](https://clevver.org)

<br>


# Permanent Storage for Digital Assets

Published: July 2023 | Last updated: November 2024

![The above image is stored in Clevver - like all images on this website!](https://get.clevver.org/2e0cb655b8019757fe288d6d9509e78bdf510b3517c82f8941f3e772ed0b0fcb.png)

In the evolving landscape of digital asset management, [Clevver](https://clevver.org/) stands as a revolutionary solution to one of the most pressing challenges facing creators and collectors: truly permanent file storage. By leveraging blockchain technology, Clevver has created a system where digital assets become an immutable part of a public, eco-friendly blockchain, ensuring perpetual accessibility without the burden of ongoing costs or maintenance.

### The Current Challenge in Digital Asset Storage

The NFT market currently faces a critical vulnerability that threatens the very foundation of digital asset ownership. While NFTs have revolutionized digital art and collectibles, they typically rely on IPFS (Interplanetary File System) or similar services for storing their underlying digital assets. This separation between the NFT's smart contract and its associated digital content creates a significant risk that many collectors may not fully understand.

Consider a scenario that has already played out multiple times in the NFT space: An artist creates a digital artwork and uploads it to a pinning service like Pinata. They mint an NFT, which sells for a substantial sum after several transactions. However, the original artist maintains responsibility for the Pinata account that hosts the actual artwork. If that account lapses due to an expired credit card, career change, or any number of life events, the [valuable digital asset becomes inaccessible](https://decrypt.co/62037/missing-or-stolen-nfts-how-to-protect). The NFT remains, but its connection to the art it represents is severed, [potentially rendering a significant investment worthless](https://www.theverge.com/2021/3/25/22349242/nft-metadata-explained-art-crypto-urls-links-ipfs).

### The Clevver Solution

Clevver approaches this challenge with a fundamentally different philosophy. Rather than storing references to files or relying on third-party services, Clevver encodes the entire digital file directly onto the blockchain. This integration creates a permanent, unbreakable link between the NFT and its associated digital asset. When an artist uploads their work to Clevver, they receive a unique, permanent URL that will remain accessible as long as the blockchain exists – no maintenance required, no recurring fees, no account management needed.

This innovation transforms the way we think about digital asset storage. By storing files "with the money" on the blockchain, Clevver ensures perfect alignment between an NFT and its underlying asset. This alignment eliminates the vulnerability of intermediary dependencies and provides true permanence without ongoing costs or maintenance requirements.

### Impact on the Digital Art Market

For artists, [Clevver](https://clevver.org/) represents a significant advancement in how they can present and sell their digital works. The guarantee of permanent storage adds inherent value to their NFTs, enabling them to command higher prices while relieving them of ongoing storage management responsibilities. Artists can focus on creation, knowing their work will remain accessible to collectors indefinitely.

Collectors benefit equally from this innovation. The assurance of permanent asset accessibility not only protects their investments but opens new financial opportunities. NFTs stored through Clevver can be confidently used as collateral in financial instruments, as their underlying assets are guaranteed to remain accessible. This permanence enables collectors to hold assets for extended periods or explore new forms of income generation through their collections.

### Technical Differentiation

While other storage solutions like IPFS, Storj, Sia, and Filecoin serve important roles in the digital ecosystem, they fundamentally differ from Clevver's approach. These platforms either require ongoing maintenance or rely on distributed storage networks with potential points of failure. Traditional cloud storage demands continuous payment and account management. Clevver, by contrast, makes the digital asset an integral part of the blockchain itself, ensuring its preservation alongside the very infrastructure that gives NFTs their value.

### The Future of Digital Asset Preservation

Clevver represents more than just a storage solution – it's a paradigm shift in how we preserve digital assets. By solving the fundamental storage challenge in the NFT space, Clevver enables true digital ownership, enhanced asset security, and perpetual value preservation. This innovation opens new possibilities for the future of digital art, collectibles, and financial instruments built around these assets.

As the digital art market continues to mature, the importance of permanent, reliable storage solutions becomes increasingly apparent. Clevver's approach not only solves current challenges but creates new opportunities for artists, collectors, and investors to participate in the digital economy with greater confidence and security.

***

Begin securing your digital legacy today at clevver.org. With Clevver, your digital assets become truly permanent, ensuring their value and accessibility for generations to come.

*Clevver: Ensuring the permanent preservation of digital creativity.*

<br>


# Permanent Digital Archives for Journalism

Published: July 2023 | Last updated: November 2024

![The above image is stored in Clevver - like all images on this website!](https://get.clevver.org/2e0cb655b8019757fe288d6d9509e78bdf510b3517c82f8941f3e772ed0b0fcb.png)

In an era where digital news content faces unprecedented challenges of preservation and authenticity, Clevver emerges as a revolutionary solution for permanently archiving journalism. By leveraging blockchain technology, Clevver creates an immutable record of news articles, ensuring that future generations can access accurate, unaltered accounts of historical events as they were originally reported by reputable media outlets.

### The Current Crisis in Digital News Preservation

The digital age has revealed a troubling vulnerability in how we preserve our collective history through journalism. Traditional news websites frequently update, modify, or remove content. Digital archives can disappear when publications fold or change ownership. Even established archival systems are subject to technical failures, policy changes, or financial constraints. This impermanence creates gaps in our historical record and poses significant challenges for researchers, historians, and society at large.

Consider recent examples where significant news archives have been lost: media companies merging and disposing of archives, local newspapers closing and their digital archives disappearing, or historical content becoming inaccessible due to technological changes. These losses represent not just missing articles, but gaps in our understanding of how events unfolded and how they were perceived at the time they occurred.

### The Clevver Solution

Clevver approaches this challenge with a fundamentally different methodology. Rather than storing news articles on traditional servers or distributed networks, Clevver encodes the entire article directly onto an eco-friendly blockchain. This approach creates a permanent, unalterable record of news content that will remain accessible as long as the blockchain exists – no ongoing maintenance required, no recurring fees, no risk of loss through institutional changes.

When a news organization archives content through Clevver, each article receives a unique, permanent URL that serves as an eternal reference point. This preservation method ensures that the original article, including its context and timing, remains intact and accessible. Unlike traditional digital archives, content stored on Clevver cannot be altered, deleted, or manipulated, providing an authentic historical record of how events were reported.

### Preserving Journalistic Integrity

For news organizations, Clevver represents a transformative tool in maintaining their role as chroniclers of history. The guarantee of permanent, immutable storage means that their reporting becomes part of an enduring public record. This permanence adds significant value to their work, ensuring that investigative journalism, breaking news coverage, and in-depth analysis remain accessible and verifiable indefinitely.

This level of preservation also serves a crucial role in combating misinformation. When articles are permanently preserved in their original form, it becomes possible to trace how stories developed, what was reported when, and how understanding of events evolved over time. This immutable record helps maintain accountability and provides a reliable reference point for fact-checking and historical research.

### Technical Distinction

While traditional archival systems and distributed storage solutions serve important roles, they fundamentally differ from Clevver's approach. Services like the Internet Archive, while valuable, rely on continuous funding and maintenance. Traditional digital archives require ongoing server maintenance and are vulnerable to technical failures or institutional changes. Clevver, by contrast, makes each article an integral part of the blockchain itself, ensuring its preservation alongside the blockchain's infrastructure.

### The Future of Historical Documentation

Clevver represents more than just a storage solution – it's a paradigm shift in how we preserve our collective history. By solving the fundamental challenge of digital content preservation, Clevver enables:

The creation of an unalterable historical record that scholars, researchers, and future generations can rely upon. A permanent archive of how significant events were reported and understood at the time they occurred. A reliable foundation for studying the evolution of public discourse and understanding of major events.

As digital journalism continues to evolve, the importance of permanent, reliable archives becomes increasingly critical. Clevver's approach not only solves current preservation challenges but creates new opportunities for news organizations to ensure their reporting becomes part of humanity's permanent historical record.

### Impact on Historical Documentation

For historians and researchers, Clevver provides an unprecedented resource: a permanent, unalterable archive of contemporary journalism. This preservation ensures that future generations will have access to authentic historical records, unaffected by the technological changes, institutional failures, or political pressures that have historically threatened archival preservation.

The implications for academic research, historical documentation, and public understanding are profound. With Clevver, we can maintain a clear, verifiable record of how events were reported and understood as they unfolded, providing invaluable context for future study and understanding.

***

Start preserving history today at clevver.org. With Clevver, your journalism becomes part of humanity's permanent record, ensuring its value and accessibility for generations to come.

*Clevver: Ensuring the permanent preservation of journalism and history.*

<br>


# How did Clevver originate?

Published: July 2023 | Last updated: November 2024

The Lynx blockchain was designed to be an eco-friendly, public blockchain specifically used for data storage. The Logware API is an easy-to-use gateway for customers to automatically and permanently store data.

During the NFT craze starting in 2021, it became apparent that a permanent data storage solution was needed for the image asset portion of an NFT. While the provenance data of the NFT is stored on a smart contract platform and can't be lost or manipulated, the art asset needs the same level of reliable integrity.&#x20;

{% hint style="info" %}
NFT collectors are looking for unique features that will drive value and, sometimes, utility. Collectors are interested in acquiring NFTs that have the characteristic of being forever accessible as a built-in trait. This provides peace of mind that the image of the NFT will never be lost or changed, and with time, high-value NFTs can be collateralized due to the permanent storage feature of the digital file.
{% endhint %}

Since the Lynx development team created Logware and corporate customers were already using the API successfully, a small 'reference application' was deployed to allow creatives to store digital files easily with a drag and drop user interface.&#x20;

![](https://get.clevver.org/2e0cb655b8019757fe288d6d9509e78bdf510b3517c82f8941f3e772ed0b0fcb.png)

The [Clevver website](https://clevver.org/) allows individuals to store a single file for free once a day. If an artist or project needs to keep large numbers of images, they can use the Clevver desktop application for bulk drag and drop simplicity for permanent image storage. While the Clevver website is free, the use of the desktop application requires a license per project.

If your NFT project would benefit from forever storage of the art files, please contact us.&#x20;


# Shortened URL Support

Published: July 2023 | Last updated: November 2024

After a file is stored in Clevver,  the user is provided a permanent URL to access the file. An example is below. The format of the file will always be the same length and structure. The link format will always start with HTTPS; the host 'get.clevver.org' is the domain name. The 64-character string is the unique identifier of the file on the blockchain. This identifier for your respective file will never change. The three-character file extension will always be appended to the end of the URL. The URL will always be 92 characters in length.&#x20;

> <https://get.clevver.org/5e24f4e015cf304ae46e3dc2b240412d41db5e1065f0b90cf7bab913085c0f65.pdf>

While the above URL can be used on websites, documentation, email correspondence, and code, the URL can be too long for some use cases—specifically, inclusion in smart contracts. So a shorter version format is listed below. The shorter version can be included in smart contract code and other scenarios where field length restrictions are of concern. The URL will always be 52 characters in length.

> <https://clevver.org/5e24f4e0ae46e3dc2b240412085c0f65>

### Clvr.ly Domain Support

Beginning in August 2022, any files created in Clevver will also be assigned a specially branded, shortened URL. Files created before August 22 will manually be assigned short URLs too. The shortened URL structure provides a 48-character length URL. The short URL does not include a file extension.

> <https://clvr.ly/5e24f4e0ae46e3dc2b240412085c0f65>

The shortened URL above links to the same file above, and it includes a particular caching tier that works well for NFT applications. The shortened URL is conveniently under the URI length limitation imposed by some smart contract platforms. There is no extra fee to get or use the shortened URL for a Clevver asset.


# Assigning Tags to Assets

Assigning Tags to Assets is the best way to keep your files organized.

There are three ways to assign a tag to an asset in your Clevver account.

* Fastest: In the Tag field, type the tag name and hit return.
* Medium: In the Tag field, type the first letter of your intended tag to reuse, select it from the dropdown list. No need to hit return. That tag is assigned.
* Slowest: Type the Tag name and then click the Add button.

The video below will show you how this is done. We recommend tagging all Assets in your account. They will be easier to find later and you can be as creative as you like.

{% embed url="<https://www.loom.com/share/df14fc0d599244258497cbcbe0da5b22?sid=4edc8201-a0ef-417d-ad7c-dd4c0049b206>" %}
Video Demo to Assign Tags
{% endembed %}

We think adding Tags can be fun and easy. It's a great way to keep your assets organized. You can remove Tags easily and you can change tags at any time. Assign up to 100 tags to an asset. The more tags you assign, the easier it will be for you to find your assets later.


# How to delete content on Clevver

Published: July 2023 | Last updated: January 2026

{% hint style="info" %}
Clevver provides 10MB of free storage for new accounts. Try it risk free, but be sure to read the [Terms of Service](/clevver/clevver-terms-of-service-agreement).
{% endhint %}

### **Understanding Encryption and Data Privacy on Clevver**

Clevver implements end-to-end encryption for all data stored on the Lynx blockchain. This encryption serves two critical purposes: protecting digital rights and respecting content ownership preferences.

#### **Copyright and Ownership**

You may upload and store any digital content that you own or have the legal right to use, including your own copyright-protected materials such as personal documents, photographs, creative works, or business assets. Clevver's encryption ensures your proprietary content remains secure and accessible only to those you authorize.

However, uploading copyrighted material that you do not own or have permission to use violates [Clevver's Terms of Service](/clevver/clevver-terms-of-service-agreement). All users must read and agree to these terms before using the platform.

#### **How Encryption Protects Content**

Once data is committed to the blockchain, it becomes permanently stored and cannot be edited or deleted—this is a fundamental characteristic of blockchain technology. However, Clevver's encryption layer provides a crucial control mechanism:

* All content is encrypted before being stored on the blockchain
* Access to content requires valid encryption keys maintained by Clevver
* If content violates Terms of Service or a copyright claim is received, Clevver can revoke access by breaking the encryption link
* The data remains on the blockchain, but becomes permanently inaccessible without the encryption keys

This approach allows Clevver to comply with legal requirements and respect intellectual property rights while leveraging the immutability of blockchain storage.

#### **Managing Your Own Content**

You maintain full control over content you've uploaded. To remove access to your own files:

1. **Archive the asset** - This removes it from your Dashboard view and strips associated tags
2. **Navigate to the Archive view** - Access your archived content
3. **Delete the asset** - From the asset detail view, permanently revoke access

Once deletion is complete, the encryption keys are destroyed and access cannot be restored—even by Clevver. The underlying blockchain data persists, but without the encryption keys, it becomes permanently inaccessible gibberish.

#### **Your Privacy is Protected**

Nothing is ever uploaded to Clevver or stored on the blockchain in an unencrypted state. This encryption-first approach protects your sensitive information, ensures your proprietary content remains confidential, and gives you control over who can access your stored assets.

#### **Content Removal Timeline**

When content is deleted or flagged for removal from Clevver, the process may take several days to complete fully. This delay is due to Clevver's multi-tier caching architecture, which is designed to ensure fast, reliable access to stored content globally.

Once an asset is marked for deletion, it is immediately flagged across all systems. However, the content will gradually disappear from various caching layers as each tier expires on its own schedule. This staged removal process ensures system stability while the encryption keys are systematically revoked across the distributed infrastructure.

During this transition period, some cached versions may remain temporarily accessible until all cache layers have been cleared and the encryption links are fully severed.


# Clevver Terms of Service Agreement

Published: January 2025 | Last updated: January 2025

### 1. Introduction

Welcome to Clevver.org ("Clevver"), a blockchain-based data storage service utilizing the Lynx blockchain. By using our service, you agree to be bound by these Terms of Service ("Terms"). Please read them carefully before proceeding.

### 2. Definitions

* "Service" refers to Clevver.org, our Lynx blockchain-based data storage platform
* "Asset" refers to any digital file or content you upload to our platform
* "We," "us," and "our" refer to Clevver
* "You" and "your" refer to the user of our Service

### 3. Payment and Storage Quota Terms

3.1. Storage Quota System

3.1.1. Purchase and Usage:

* Users must purchase storage space ("quota") in advance
* Quota can be used at any time after purchase to store Assets
* Users can purchase additional quota at any time, even before existing quota is depleted
* Additional quota must be purchased when existing quota is depleted to store new Assets
* Quota represents the maximum amount of storage space available for your Assets
* No monthly fees
* No annual fees

3.1.2. Pricing:

* Quota prices are subject to change at any time without notice
* Changes in quota prices do not affect previously purchased quota
* Current pricing will be displayed on the website at time of purchase

3.1.3. Expiration:

* Unused quota expires three (3) years from the date of purchase
* Expiration is enforced at the discretion of Clevver management
* No refunds will be issued for expired quota

3.2. Refund Policy

3.2.1. All payments are final and non-refundable, including cases where:

* Your content is made permanently inaccessible due to Terms of Service violations
* You change your mind about storing the content
* You accidentally upload the wrong content
* Your quota expires

### 4. Prohibited Content

You agree not to upload, store, or distribute any Assets that:

4.1. Contain pornographic, sexually explicit, or adult content

4.2. Contain graphic violence, gore, or extreme cruelty

4.3. Promote hate speech, discrimination, or harmful content targeting any individual or group based on:

* Race
* Ethnicity
* Religion
* Gender
* Sexual orientation
* Disability
* Age
* National origin

4.4. Violate copyright, trademark, or intellectual property rights, including:

* Pirated software
* Unauthorized copies of digital media
* Stolen content
* Content that infringes on others' intellectual property rights

4.5. Promote or contain:

* Misinformation
* Disinformation
* Malicious propaganda
* Revenge content
* Cyberbullying materials

### 5. Content Enforcement and Access Restriction

5.1. We reserve the right to make any Asset permanently inaccessible through our platform at our sole discretion, without prior notice or refund, if we determine it violates these Terms. Note that while the Asset will remain on the Lynx blockchain, it will no longer be accessible through Clevver's interface.

5.2. Enforcement of these Terms is at our sole discretion. We may choose to enforce, not enforce, or selectively enforce any part of these Terms. Our choice to enforce one provision does not obligate us to enforce other provisions, nor does it waive our right to enforce the same provision in the future.

5.3. We will cooperate with law enforcement and regulatory authorities by:

* Reporting illegal activities
* Providing necessary information about violations
* Assisting in investigations related to illegal content or activities

### 6. Public Nature of Storage

6.1. All Assets stored through our Service are:

* Permanently stored on the Lynx blockchain
* Publicly accessible only through Clevver.org
* Permanently stored and unable to be deleted from the Lynx blockchain due to the nature of blockchain technology
* Not directly accessible on the Lynx blockchain or through any other website or service

6.2. Access Exclusivity:

* Assets can only be accessed through Clevver.org's interface
* Direct access to assets on the Lynx blockchain is not possible
* Third-party websites and services cannot access or display your assets

6.3. Privacy Responsibility:

* You are solely responsible for encrypting any sensitive data before uploading
* We make no guarantees about the privacy of unencrypted data
* We are not responsible for any consequences of public access to your unencrypted Assets

### 7. Liability and Indemnification

7.1. You agree to indemnify and hold us harmless from any claims, damages, losses, liabilities, costs, and expenses (including reasonable attorneys' fees) arising from:

* Your use of the Service
* Your violation of these Terms
* Your violation of any rights of another party
* Your uploaded Assets

7.2. We are not responsible for:

* Loss of data
* Unauthorized access to unencrypted Assets
* Any consequences of the public nature of blockchain storage

### 8. Modifications to Terms

8.1. We reserve the right to modify these Terms at any time. Continued use of the Service after changes constitutes acceptance of the modified Terms.

### 9. Termination

9.1. We reserve the right to terminate or suspend your access to the Service at any time, without prior notice or liability, for any reason, including violation of these Terms.

### 10. Governing Law

10.1. These Terms shall be governed by and construed in accordance with the laws of North Carolina, United States of America, without regard to its conflict of law provisions.

### 11. Platform Security and Prohibited Activities

11.1. Platform Interference:

* Users agree not to attempt to deconstruct, hack, damage, or otherwise interfere with Clevver's normal operations
* Users shall not attempt to reverse engineer or circumvent any of Clevver's systems or functions
* Any attempts to compromise, exploit, or bypass platform security measures are strictly prohibited
* Users shall not engage in activities that may disrupt or degrade the service for other users

11.2. Consequences of Violation:

* We reserve the right to immediately make all user content permanently inaccessible if violations occur
* All purchased quota will be forfeited without refund if platform security is compromised
* Legal action may be pursued for serious violations
* We may report security violations to relevant authorities

### 12. Bandwidth and Access Limitations

12.1. Usage Restrictions:

* Assets hosted through Clevver and displayed on external websites or applications are subject to bandwidth monitoring
* Excessive bandwidth consumption may result in access throttling
* We reserve the right to implement rate limiting on high-traffic assets
* The definition of "extraordinary" bandwidth usage is at our sole discretion

12.2. Throttling Implementation:

* Access speeds may be reduced for assets consuming excessive bandwidth
* Throttling may be implemented without prior notice
* Throttling measures will remain in effect until bandwidth usage returns to acceptable levels
* Users with consistent high-bandwidth requirements should contact us for alternative solutions

### 12. Contact Information

For questions about these Terms, please contact us at <https://clevver.org>

By using our Service, you acknowledge that you have read, understood, and agree to be bound by these Terms of Service.


# Public Methods

Clevver file storage works by creating Jobs which store one or more files on the block chain.

## Get active batch jobs.

<mark style="color:blue;">`GET`</mark> `https://clevver.org/api/batches`

The process of storing files on the blockchain can take some time and is an asynchronous process. This request will return a list of actively running batch storage jobs.

{% tabs %}
{% tab title="200: OK " %}

```json
{
  "status": "success",
  "data": [
    {
      "id": "5c893d75-2a8b-4712-b56f-89377ac97681",
      "status": "processing",
      "progress": 10.3,
      "created_at": "2023-11-01 13:53:12"
    },
    {
      "id": "0adc8bf2-ec4a-415e-8074-cba50dd9e0b4",
      "status": "processing",
      "progress": 97,
      "created_at": "2023-11-01 13:48:12"
    },
  ]
}
```

{% endtab %}
{% endtabs %}

## Create a new batch

<mark style="color:green;">`POST`</mark> `https://clevver.org/api/batches`

In order to store files on Clevver, you must first create a batch. Files can then be attached to the batch and later started by calling the start method.

{% tabs %}
{% tab title="201: Created " %}

```json
{
  "status": "success",
  "data": {
      "id": "5c893d75-2a8b-4712-b56f-89377ac97681",
      "status": "created",
      "progress": 0,
      "created_at": "2023-11-01 13:53:12",
      "message": "Batch created successfully"
  }
}
```

{% endtab %}
{% endtabs %}

## Start a storage job

<mark style="color:green;">`POST`</mark> `https://clevver.org/api/batches/{batch_id}/start`

Once a storage job has been created and files have been attached to it, you can then start the job. Starting the job will begin the process of storing the files onto the blockchain.

#### Path Parameters

| Name                               | Type   | Description         |
| ---------------------------------- | ------ | ------------------- |
| <mark style="color:red;">\*</mark> | String | The id of the batch |

{% tabs %}
{% tab title="200: OK " %}

```json
{
  "status": "success",
  "data": {
      "id": "5c893d75-2a8b-4712-b56f-89377ac97681",
      "status": "processing",
      "progress": 0,
      "created_at": "2023-11-01 13:53:12",
      "message": "Batch job started"
  }
}
```

{% endtab %}
{% endtabs %}

## Get a storage job's status

<mark style="color:blue;">`GET`</mark> `https://clevver.org/api/batches/{batch_id}`

You can query individual batches to check their status and/or progress.

#### Path Parameters

| Name                               | Type   | Description         |
| ---------------------------------- | ------ | ------------------- |
| <mark style="color:red;">\*</mark> | String | The id of the batch |

{% tabs %}
{% tab title="200: OK The requested batch object's status" %}

```json
{
  "status": "success",
  "data": {
      "id": "5c893d75-2a8b-4712-b56f-89377ac97681",
      "status": "delivered",
      "progress": 100,
      "created_at": "2023-11-01 13:53:12",
  }
}
```

{% endtab %}
{% endtabs %}


# Batches

Clevver file storage works by creating batches which store one or more files on the block chain.

## Get active batch jobs.

<mark style="color:blue;">`GET`</mark> `https://clevver.org/api/batches`

The process of storing files on the blockchain can take some time and is an asynchronous process. This request will return a list of actively running batch storage jobs.

{% tabs %}
{% tab title="200: OK " %}

```json
{
  "status": "success",
  "data": [
    {
      "id": "5c893d75-2a8b-4712-b56f-89377ac97681",
      "status": "processing",
      "progress": 10.3,
      "created_at": "2023-11-01 13:53:12"
    },
    {
      "id": "0adc8bf2-ec4a-415e-8074-cba50dd9e0b4",
      "status": "processing",
      "progress": 97,
      "created_at": "2023-11-01 13:48:12"
    },
  ]
}
```

{% endtab %}
{% endtabs %}

## Create a new batch

<mark style="color:green;">`POST`</mark> `https://clevver.org/api/batches`

In order to store files on Clevver, you must first create a batch. Files can then be attached to the batch and later started by calling the start method.

{% tabs %}
{% tab title="201: Created " %}

```json
{
  "status": "success",
  "data": {
      "id": "5c893d75-2a8b-4712-b56f-89377ac97681",
      "status": "created",
      "progress": 0,
      "created_at": "2023-11-01 13:53:12",
      "message": "Batch created successfully"
  }
}
```

{% endtab %}
{% endtabs %}

## Start a storage job

<mark style="color:green;">`POST`</mark> `https://clevver.org/api/batches/{batch_id}/start`

Once a storage job has been created and files have been attached to it, you can then start the job. Starting the job will begin the process of storing the files onto the blockchain.

#### Path Parameters

| Name                                        | Type   | Description         |
| ------------------------------------------- | ------ | ------------------- |
| batch\_id<mark style="color:red;">\*</mark> | String | The id of the batch |

{% tabs %}
{% tab title="200: OK " %}

```json
{
  "status": "success",
  "data": {
      "id": "5c893d75-2a8b-4712-b56f-89377ac97681",
      "status": "processing",
      "progress": 0,
      "created_at": "2023-11-01 13:53:12",
      "message": "Batch job started"
  }
}
```

{% endtab %}
{% endtabs %}

## Get a storage job

<mark style="color:blue;">`GET`</mark> `https://clevver.org/api/batches/{batch_id}`

You can query individual batches to check their status and/or progress.

#### Path Parameters

| Name                                        | Type    | Description         |
| ------------------------------------------- | ------- | ------------------- |
| batch\_id<mark style="color:red;">\*</mark> | Strring | The id of the batch |

{% tabs %}
{% tab title="200: OK The requested batch object" %}

```json
{
  "status": "success",
  "data": {
      "id": "5c893d75-2a8b-4712-b56f-89377ac97681",
      "status": "delivered",
      "progress": 100,
      "created_at": "2023-11-01 13:53:12",
  }
}
```

{% endtab %}
{% endtabs %}

## Upload and attach a file to a batch

<mark style="color:green;">`POST`</mark> `https://clevver.org/api/batches/{batch_id}/files`

In order to store files on the block chain they must first be attached to a batch.

#### Path Parameters

| Name                                        | Type   | Description         |
| ------------------------------------------- | ------ | ------------------- |
| batch\_id<mark style="color:red;">\*</mark> | String | The id of the batch |

#### Request Body

| Name                                   | Type | Description             |
| -------------------------------------- | ---- | ----------------------- |
| file<mark style="color:red;">\*</mark> | File | The file being uploaded |

{% tabs %}
{% tab title="200: OK The requested batch object" %}

```json
{
{
    "message": "Asset successfully uploaded",
    "status": "success",
    "data": {
        "id": "d37dffe9-60d5-4df4-ae0c-93bf42ac2137",
        "status": "created",
        "file": {
            "url": "/uploads/digital_asset/file/d37dffe9-60d5-4df4-ae0c-93bf42ac2137/myphoto.png",
            "thumb": {
                "url": "/uploads/digital_asset/file/d37dffe9-60d5-4df4-ae0c-93bf42ac2137/thumb_myphoto.png"
            }
        },
        "file_size": 1752887,
        "estimated_cost": null,
        "created_at": "2024-01-24T05:32:50.692Z",
        "updated_at": "2024-01-24T05:32:50.692Z",
        "txid": null,
        "task_id": null,
        "serialized_metadata": "{}",
        "should_be_cached": true,
        "stored_on": null,
        "short_slug": null,
        "checksum": "f604699904334d333b17b872b1183d22f604699904334d333b17b872b1183d22",
        "user_id": 2,
        "name": "myphoto.png",
        "archived": false,
        "duplicate": false,
        "tag_list": []
    }
}
```

{% endtab %}
{% endtabs %}


# Files

Files stuff here.

## Get a list of unarchived files associated with your account.

<mark style="color:blue;">`GET`</mark> `https://clevver.org/api/files`

#### Query Parameters

| Name     | Type    | Description                                                        |
| -------- | ------- | ------------------------------------------------------------------ |
| archived | Boolean | When true returns archived files (default: false)                  |
| filter   | String  | When 'untagged' returns only untagged files. (default: no filter.) |
| tags     | String  | A comma delimited list of tags                                     |
| page     | Integer | The page number to retrieve                                        |

{% tabs %}
{% tab title="200: OK Paginated List of files" %}

```json
{
    "data": [
        {
            "id": "95668cc0-1695-46cb-9a15-db16944e6f98",
            "user_id": 1,
            "name": "Monthly Report Jan 2024",
            "filename": "somefile.pdf",
            "file_size": 58404,
            "url": "https://get.clevver.org/4354c6f90a49ca0e1884be4226c56750f078ee74db53109ac6e5807425fbf30a.pdf",
            "forever_url": "https://clvr.ly/4354c6f90a49ca0e1884be4226c56750.pdf",
            "thumb_url": "/uploads/digital_asset/file/95668cc0-1695-46cb-9a15-db16944e6f98/thumb_365233683_214917471203265_1617498711144221366_n.png",
            "cdn_url": "https://clvr.ly/4354c6f90a49ca0e1884be4226c56750",
            "txid": "1dc65cefbb656fb124c6beed75cbe4c0218f94966c6e524911b03740730ea7b0",
            "content_type": "application/pdf",
            "status": "cached",
            "archived": false,
            "preview_type": "pdf",
            "created_at": "2024-01-24T05:26:54.172Z",
            "updated_at": "2024-01-25T04:42:43.458Z",
            "tags": ["report", "january", "2024"]
        }
    ],
    "meta": {
        "tags": ["report", "january", "2024", "december", "november", "2023"],
        "tag_counts": {
            "report": 3,
            "january": 1,
            "2024": 1,
            "december": 1,
            "november": 1,
            "2023": 2
        }
    },
    "pagination": {
        "total_entries": 1,
        "total_pages": 1,
        "current_page": 1,
        "next_page": null,
        "previous_page": null,
        "per_page": 10
    }
}
```

{% endtab %}
{% endtabs %}

## Retrieve data about a specific file

<mark style="color:blue;">`GET`</mark> `https://clevver.org/api/files/{file_id}`

#### Path Parameters

| Name                                       | Type   | Description        |
| ------------------------------------------ | ------ | ------------------ |
| file\_id<mark style="color:red;">\*</mark> | String | The id of the file |

{% tabs %}
{% tab title="200: OK The file data" %}

```json
{
    "message": "File loaded",
    "status": "success",
    "data": {
        "id": "95668cc0-1695-46cb-9a15-db16944e6f98",
        "user_id": 1,
        "name": "Monthly Report Jan 2024",
        "filename": "somefile.pdf",
        "file_size": 58404,
        "url": "https://get.clevver.org/4354c6f90a49ca0e1884be4226c56750f078ee74db53109ac6e5807425fbf30a.pdf",
        "forever_url": "https://clvr.ly/4354c6f90a49ca0e1884be4226c56750.pdf",
        "thumb_url": "/uploads/digital_asset/file/95668cc0-1695-46cb-9a15-db16944e6f98/thumb_365233683_214917471203265_1617498711144221366_n.png",
        "cdn_url": "https://clvr.ly/4354c6f90a49ca0e1884be4226c56750",
        "txid": "1dc65cefbb656fb124c6beed75cbe4c0218f94966c6e524911b03740730ea7b0",
        "content_type": "application/pdf",
        "status": "cached",
        "archived": false,
        "preview_type": "pdf",
        "created_at": "2024-01-24T05:26:54.172Z",
        "updated_at": "2024-01-25T04:42:43.458Z",
        "tags": ["report", "january", "2024"]
    }
}
```

{% endtab %}

{% tab title="404: Not Found Error response" %}

```json
{
    "error": "File not found",
    "status": "error",
    "data": []
}
```

{% endtab %}
{% endtabs %}

## Update a file

<mark style="color:orange;">`PUT`</mark> `https://clevver.org/api/{file_id}`

#### Path Parameters

| Name                                       | Type   | Description                  |
| ------------------------------------------ | ------ | ---------------------------- |
| file\_id<mark style="color:red;">\*</mark> | String | The id of the file to update |

#### Query Parameters

| Name    | Type   | Description                   |
| ------- | ------ | ----------------------------- |
| tags\[] | String | An array of tags for the file |
| name    | String | The name (title) of the file  |

{% tabs %}
{% tab title="200: OK File was updated successfully" %}

```json
{
    "message": "File updated",
    "status": "success",
    "data": {
        "id": "95668cc0-1695-46cb-9a15-db16944e6f98",
        "user_id": 1,
        "name": "Monthly Financial Report Jan 2024",
        "filename": "somefile.pdf",
        "file_size": 58404,
        "url": "https://get.clevver.org/4354c6f90a49ca0e1884be4226c56750f078ee74db53109ac6e5807425fbf30a.pdf",
        "forever_url": "https://clvr.ly/4354c6f90a49ca0e1884be4226c56750.pdf",
        "thumb_url": "/uploads/digital_asset/file/95668cc0-1695-46cb-9a15-db16944e6f98/thumb_365233683_214917471203265_1617498711144221366_n.png",
        "cdn_url": "https://clvr.ly/4354c6f90a49ca0e1884be4226c56750",
        "txid": "1dc65cefbb656fb124c6beed75cbe4c0218f94966c6e524911b03740730ea7b0",
        "content_type": "application/pdf",
        "status": "cached",
        "archived": false,
        "preview_type": "pdf",
        "created_at": "2024-01-24T05:26:54.172Z",
        "updated_at": "2024-01-25T04:42:43.458Z",
        "tags": ["report", "january", "2024", "finance"]
    }
}
```

{% endtab %}

{% tab title="404: Not Found " %}

{% endtab %}
{% endtabs %}

## Archive a file

<mark style="color:purple;">`PATCH`</mark> `https://clevver.org/apifiles/{file_id}/archive`

#### Path Parameters

| Name     | Type   | Description                   |
| -------- | ------ | ----------------------------- |
| file\_id | String | The id of the file to archive |

{% tabs %}
{% tab title="200: OK " %}

```json
{
    "message": "File archived",
    "status": "success",
    "data": {
        "id": "95668cc0-1695-46cb-9a15-db16944e6f98",
        "user_id": 1,
        "name": "Monthly Report Jan 2024",
        "filename": "somefile.pdf",
        "file_size": 58404,
        "url": "https://get.clevver.org/4354c6f90a49ca0e1884be4226c56750f078ee74db53109ac6e5807425fbf30a.pdf",
        "forever_url": "https://clvr.ly/4354c6f90a49ca0e1884be4226c56750.pdf",
        "thumb_url": "/uploads/digital_asset/file/95668cc0-1695-46cb-9a15-db16944e6f98/thumb_365233683_214917471203265_1617498711144221366_n.png",
        "cdn_url": "https://clvr.ly/4354c6f90a49ca0e1884be4226c56750",
        "txid": "1dc65cefbb656fb124c6beed75cbe4c0218f94966c6e524911b03740730ea7b0",
        "content_type": "application/pdf",
        "status": "cached",
        "archived": true,
        "preview_type": "pdf",
        "created_at": "2024-01-24T05:26:54.172Z",
        "updated_at": "2024-01-25T04:42:43.458Z",
        "tags": ["report", "january", "2024"]
    }
}
```

{% endtab %}
{% endtabs %}

## Unarchive a file

<mark style="color:purple;">`PATCH`</mark> `https://clevver.org/apifiles/{file_id}/unarchive`

#### Path Parameters

| Name     | Type   | Description                     |
| -------- | ------ | ------------------------------- |
| file\_id | String | The id of the file to unarchive |

{% tabs %}
{% tab title="200: OK " %}

```json
{
    "message": "File restored",
    "status": "success",
    "data": {
        "id": "95668cc0-1695-46cb-9a15-db16944e6f98",
        "user_id": 1,
        "name": "Monthly Report Jan 2024",
        "filename": "somefile.pdf",
        "file_size": 58404,
        "url": "https://get.clevver.org/4354c6f90a49ca0e1884be4226c56750f078ee74db53109ac6e5807425fbf30a.pdf",
        "forever_url": "https://clvr.ly/4354c6f90a49ca0e1884be4226c56750.pdf",
        "thumb_url": "/uploads/digital_asset/file/95668cc0-1695-46cb-9a15-db16944e6f98/thumb_365233683_214917471203265_1617498711144221366_n.png",
        "cdn_url": "https://clvr.ly/4354c6f90a49ca0e1884be4226c56750",
        "txid": "1dc65cefbb656fb124c6beed75cbe4c0218f94966c6e524911b03740730ea7b0",
        "content_type": "application/pdf",
        "status": "cached",
        "archived": false,
        "preview_type": "pdf",
        "created_at": "2024-01-24T05:26:54.172Z",
        "updated_at": "2024-01-25T04:42:43.458Z",
        "tags": ["report", "january", "2024"]
    }
}
```

{% endtab %}
{% endtabs %}


# User

## Retrieve information about your user account

<mark style="color:blue;">`GET`</mark> `https://clevver.org/api/user`

{% tabs %}
{% tab title="200: OK " %}

````json
```json
{
    "data": {
        "id": 1,
        "email_address": "your-email@example.com",
        "max_file_size": 104857600
    }
}
```
````

{% endtab %}
{% endtabs %}

## Retrieve information about your account's quota

<mark style="color:blue;">`GET`</mark> `https://clevver.org/api/userr/quota`

{% tabs %}
{% tab title="200: OK " %}

```json
{
    "status": "sucess",
    "data": {
        "total": 2097152,
        "used": 429380,
        "available": 1667772,
        "percentage_used": 20.47443389892578
    }
}
```

{% endtab %}
{% endtabs %}


# ElectrumX Server Infrastructure

Published: January 2026 | Last updated: January 2026

### **Why ElectrumX Nodes Matter for Lynx**

As a UTXO-based blockchain derived from Bitcoin, Lynx relies on the Unspent Transaction Output (UTXO) model for tracking coin ownership and balances. ElectrumX servers play a critical role in making this data accessible to lightweight wallets and third-party applications without requiring users to download and sync the entire blockchain.

Traditional full nodes must download every block in the blockchain's history—a process that can take days and consume hundreds of gigabytes of storage. ElectrumX servers solve this problem by maintaining indexed UTXO databases that allow wallets to:

* Query balance information instantly without blockchain synchronization
* Verify transactions quickly using SPV (Simplified Payment Verification)
* Broadcast transactions to the network efficiently
* Access historical transaction data on demand
* Operate on mobile devices and resource-constrained hardware

For UTXO-based projects like Lynx, ElectrumX infrastructure is essential for wallet developers building lightweight clients, mobile applications, and web-based interfaces. These servers act as a bridge between the full blockchain and end-user applications, enabling fast, responsive wallet experiences without sacrificing security or decentralization.

### **Public ElectrumX Nodes**

The following public ElectrumX nodes are available for integration and inclusion with third-party wallets and development partners. Members of the Lynx community donate generous time and resources to ensure these globally distributed ElectrumX nodes remain operational, performant, and synchronized with the latest blockchain state.

```
electrum5.getlynx.io # Milan
electrum6.getlynx.io # Sydney
electrum7.getlynx.io # Chicago
electrum8.getlynx.io # Frankfurt
electrum9.getlynx.io # Toronto
```

{% hint style="warning" %}
Secure ElectrumX ports for Lynx are 50002 and 50004. A non-secure port is not supported.
{% endhint %}

By maintaining multiple geographically distributed ElectrumX servers, the Lynx network ensures reliable access for wallet developers and users worldwide, reducing latency and providing redundancy against server outages.

### **Monitoring and Status**

The operational status of all public Lynx service nodes is [available for real-time inspection](https://status.getlynx.io/). A comprehensive ElectrumX uptime monitoring dashboard tracks node availability, synchronization status, and blockchain height consistency across all servers. [This monitoring tool](https://1209k.com/bitcoin-eye/ele.php?chain=lynx) ensures all ElectrumX nodes remain online and properly synchronized with identical block heights. In the event of a service disruption or synchronization issue, the system automatically notifies the Lynx Core team for immediate remediation, ensuring minimal downtime and consistent service quality for wallet developers and end users.


# Build Instructions

The following guide will help you build your own ElectrumX Lynx node quickly

{% hint style="danger" %}
Building an ElectrumX on a Raspberry Pi is not recommended unless you ensure the Pi has a public IP address and permanent direct access to the web. It should have +4GB of RAM.
{% endhint %}

* Debian 11 is required. The build script is explicitly designed for Debian 11.
* This is for a CLI-only version of Debian. A desktop version of Debian is not recommended.
* Create a VPS instance with at least 2GB of RAM.
* The VPS should have no other services installed. This VPS instance will be a dedicated public Lynx node, Electrum server, and if you enable it, Lynx miner.

{% hint style="info" %}
The following steps should be completed in the exact order.
{% endhint %}

1. Create your 2GB Debian 11 VPS instance with your vendor. We recommend [Linode](https://www.linode.com/), [Digital Ocean](https://www.digitalocean.com/), [Scaleway](https://www.scaleway.com/), etc.
2. Get the public IP4 address for the VPS and notify the [#Electrum-Team channel on the Lynx Discord](https://discord.getlynx.io/). The Administrator will configure a DNS record and name for your IP4 address.
3. As the root user on your VPS, execute the following command - be sure to replace the domain name in the last part of the command with the one provided from [Discord](https://discord.getlynx.io/).

```
wget -O - https://electrumx.getlynx.io/ | bash -s electrum.domain.com
```

1. The process will run for a few minutes and eventually reboot the VPS instance when complete. You don't have to continue to the next step right away; we recommend waiting 15 minutes before the next step.
2. Log back into the VPS with the lynx account (the root account has been locked for security). The default username and password are lynx for both.
3. You will be prompted to change the lynx password. This is normal. Set your lynx account password. If you are logged out, log back into the lynx account. Again, this is normal.
4. As the lynx user, type 'sudo su' to access the root account.
5. As the root user, copy/paste the command you used above again (don't forget the domain name you assigned at the end). Run that command again.
6. This will configure Electrum for you, set up SSL, and adjust the firewall.
7. It will display the Electrum log and show its sync progress when it is complete. You can watch it or type 'control+C' to exit. You are now done. Once Electrum completes the sync process, the Electrum services will be public.
8. Don't lose your lynx account password. We do NOT recommend enabling the wallet functions in Lynx. This is for your security.

{% hint style="success" %}
Power User: You can do this if you want to enable the built-in miner. As the lynx user, type 'lyc' and change the parameter 'disablebuiltinminer' to '0'. We recommend leaving the 'cpulimitforbuiltinminer' parameter with a value of '0.50'. For best results, use your Tipsy Miner Id in the lynx.conf file. This will get you the best results and is more efficient for the built-in miner. When done, restart lynx with the command 'sudo systemctl restart lynxd'.
{% endhint %}

{% hint style="danger" %}
If you enable the built-in miner and use too much CPU, the Electrum will run slow and the VPS vendor might ban your instance. We don't recommend running the built-in miner more than 50%.
{% endhint %}


# Build Script Details

Published: June 2024 | Last updated: April 2025

The Github Repository for the Lynx ElectrumX build script is located [here](https://github.com/getlynx/LynxElectrumBuilder).

The build script relies on a few dependencies and ties them together in a single script that completes the tedious task of building the Electrum. The scripts include;

* [LynxCI](https://github.com/getlynx/LynxCI) - the script to create a Lynx node.
* [Electrum Installer](https://github.com/MadCatMining/electrumx-installer) - from our friends at [Mad Cat Mining](https://mcmpool.eu/) - who generously upgraded the [upstream version](https://github.com/bauerj/electrumx-installer) to work with Debian 11 and the latest versions of Python for Debian 11.
* [Certbot](https://certbot.eff.org/) - to complete the task of ensuring that all connections to the Electrum remain encrypted.
* Shell scripting - the auto-configuration of Electrum configuration files, Lynx configurations files,  and local firewall settings on the node.

{% hint style="info" %}
The complete documentation for ElectrumX can be found [here](https://electrumx-spesmilo.readthedocs.io/en/latest/). All Lynx ElectrumX servers enforce secure traffic via ports 50002 and 50004. Non-secure Electrum ports are blocked.
{% endhint %}

## Reference Configuration Files

The following files are automatically configured in the [build script,](https://github.com/getlynx/LynxElectrumBuilder) but sometimes, a copy of a configuration file is helpful. Below is a template of your local /etc/electrumx.conf file.&#x20;

```bash
# This script is for electrum.getlynx.io. Be sure to update your domain below.
# File location: /etc/electrumx.conf

DB_DIRECTORY=/db
DAEMON_URL=http://{localLynxRPCUsername}:{localLynxRPCPassword}@127.0.0.1:9332/
COIN=Lynx
DB_ENGINE=rocksdb
COST_SOFT_LIMIT=0
COST_HARD_LIMIT=0
SSL_CERTFILE=/etc/letsencrypt/live/electrum5.getlynx.io/fullchain.pem
SSL_KEYFILE=/etc/letsencrypt/live/electrum5.getlynx.io/privkey.pem
SERVICES=ssl://:50002,wss://:50004,rpc://
REPORT_SERVICES=wss://electrum5.getlynx.io:50004,ssl://electrum5.getlynx.io:50002
```

The following Class should be used to correctly integrate your Electrum node with Lynx.

```bash
# For Debian 11
# File location: /usr/local/lib/python3.9/dist-packages/electrumx/lib/coins.py

# https://docs.getlynx.io/electrumx/
class Lynx(Coin):
	NAME = "Lynx"
	SHORTNAME = "LYNX"
	NET = "mainnet"
	P2PKH_VERBYTE = bytes.fromhex("2d")
	P2SH_VERBYTES = (bytes.fromhex("16"),)
	WIF_BYTE = bytes.fromhex("ad")
	GENESIS_HASH = ('984b30fc9bb5e5ff424ad7f4ec193053'
			'8a7b14a2d93e58ad7976c23154ea4a76')
	DESERIALIZER = lib_tx.DeserializerSegWit
	TX_COUNT = 1
	TX_COUNT_HEIGHT = 1
	TX_PER_BLOCK = 1
	RPC_PORT = 9332
	PEER_DEFAULT_PORTS = {'t': '50004', 's': '50002'}
	PEERS = [
		'electrum5.getlynx.io s t',
		'electrum6.getlynx.io s t',
		'electrum7.getlynx.io s t',
		'electrum8.getlynx.io s t',
		'electrum9.getlynx.io s t',
	]
	REORG_LIMIT = 5000

```


# sitemap

<https://docs.getlynx.io/2025-06-23T17:02:32+00:001.00https://docs.getlynx.io/technical-evolution-and-architecture-overview2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/history-of-lynx/evolution-of-a-blockchain2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/history-of-lynx/hybrid-proof-of-work-hpow-protocol2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/history-of-lynx/pioneering-blockchain-data-storage2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/history-of-lynx/evolution-to-proof-of-stake2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/history-of-lynx/next-generation-data-storage-architecture2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/history-of-lynx/preserving-knowledge2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/hardware-and-system-requirements2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/lynx-dynamics2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/open-source2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/core-parameters2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/sustainability2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/circulating-supply2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/locked-addresses2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/data-storage2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/data-storage/auth2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/data-storage/fetch2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/data-storage/fetchall2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/data-storage/store2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/data-storage/status2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/data-storage/list2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/understanding-the-encryption-option2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/coin-stake-maturity2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/understanding-asset-retrieval-times2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/understanding-block-time-targeting-in-the-lynx-blockchain2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-core/understanding-the-lynx-blockchain-statistics-report2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-administration/lynx-nodes2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-administration/bootstraps2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-administration/bootstraps/bootstrap-extraction-script2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-administration/bootstraps/bootstrap-creation-script2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-administration/how-to-sweep-a-lynx-wallet2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/lynx-administration/enable-disable-staking2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/clevver/revolutionizing-digital-preservation2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/clevver/true-permanent-storage-for-digital-assets2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/clevver/permanent-digital-archives-for-journalism2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/clevver/how-did-clevver-originate2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/clevver/shortened-url-support2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/clevver/assigning-tags-to-assets2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/clevver/how-to-delete-content2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/clevver/clevver-terms-of-service-agreement2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/clevver-api/public-methods2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/clevver-api/public-methods/batches2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/clevver-api/public-methods/files2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/clevver-api/public-methods/user2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/electrumx/lynx-electrumx-nodes2025-06-23T17:02:32+00:000.80https://docs.getlynx.io/electrumx/electrumx2025-06-23T17:02:32+00:000.80>


