# Welcome to the Autonomys Academy Discover the Autonomys Network & Auto Suite Learn about what Autonomys is building via our learning resources. ### Contents 1. [**AUTONOMYS VISION**](/autonomys-vision/intro-to-ai3) — Read about AI3.0, the Age of Autonomy & Autonomys' potential applications 2. [**AUTONOMYS NETWORK**](/autonomys-network/introduction) — Read about the Subspace Protocol, our network architecture, (including our unique PoAS consensus, DSN & DecEx) & protocol economics for $AI3 3. [**AUTO SUITE**](/auto-suite/introduction) — Read about Autonomys' suite of software and products, including the Auto SDK, Auto Agents Framework, Auto ID & Space Acres 4. [**ADDITIONAL LEARNING**](/additional-learning/ai-agentics) — Read about the basics of blockchain, web3, AI, agents & digital identity Join our [Discord](https://discord.com/invite/subspace-network) and message the team if you have any questions, and visit this [section](https://github.com/subspace/autonomys_gitbook/blob/main/broken-reference/README.md) to provide feedback. # A Preface for OG Subspacers An Introduction from Subspace Co-founder Jeremiah Wagstaff What is subspace? This is a question I am often asked, and lately have been asking myself more and more. As the original author of the subspace white paper and the co-founder of the company building subspace, I feel uniquely qualified to answer this question. Subspace is a novel consensus protocol and technical architecture that allows for the establishment of a network of secure, scalable, decentralized, and energy-efficient blockchains. The vision of the subspace protocol has always been to create the foundation for the next generation of global digital infrastructure. But, to be clear, subspace is still *just a technology*. This technology is certainly noteworthy, as it solves *all* of the core technical challenges facing blockchains and it does actually pave the road for mass adoption of blockchain-based applications and services. However, the subspace protocol itself does not address the far more difficult question of why we need scalable blockchain infrastructure in the first place. At the same time, despite over fifteen years of experimentation by a passionate global community, blockchains (regardless of whether or not they scale) remain an interesting technical solution that is still searching for a universal, compelling, real world problem to solve. As it stands, the most widely adopted use case of blockchain technology to date has been financial speculation, whether it be in the form of cryptocurrencies, decentralized finance (DeFi), or Web3. This hyper-focus on speculation and the numerous abuses that it has enabled, most recently demonstrated by the collapse of the FTX exchange, have tarnished the public perception of blockchain technology. For much of the world, blockchain is seen as either a way for fraudsters to pull off massive Ponzi schemes on an unsuspecting public, or a new kind of easy money that allows those who can spot the next best investment opportunity to get rich quick. The core contributors to the subspace protocol have long-sought to build a project that could break out of this speculative trap, by creating an infrastructure layer that was able to support more meaningful and impactful use cases. Up to this point, we have attempted to bridge this gap by articulating the value of subspace in terms of its technical features alone. This has proven to be a mistake. In reality, the true value of subspace does not lie in the core technology, but in what that technology enables. Until now, what subspace actually unlocks has been elusive, even to those of us who have dedicated the last six years of our lives to building it. But along our journey, the world has changed, and we would all do well to take notice. Regardless of how we feel about it, accelerating advances in Artificial Intelligence (AI) are quickly transitioning humanity into the Age of AI. It is no longer a question of if AI will surpass human intelligence, but rather how soon it will happen and what, if anything, we may do to influence the ultimate outcome. Moreover, any industry, organization, or individual who chooses to ignore AI will soon find themselves irrelevant and largely beholden to those who have instead chosen to engage with it. Subspace is no exception. While the above facts are becoming increasingly clear to the rest of the world, where we are ultimately headed and the role of blockchain in this new age remain unclear. I have chosen to engage with AI and have also sought to understand it in a systematic and holistic manner, in the same way that I approached blockchains when I began working on subspace six years ago. Given my unique perspective at the intersection of blockchain and AI, I have drawn my own conclusions regarding where we might be headed and what role blockchain may hold in helping humanity to arrive at a positive outcome. As described in greater detail below, I have become convinced that the core value proposition of blockchain technology lies in its unique ability to secure, constrain, and control AI; allowing blockchains to serve as a mediating force between humanity and ever more capable AI systems, such as Artificial General Intelligence (AGI) and Artificial Super Intelligence (ASI). In short, blockchains will help make AI safe for all humanity. Given the critical role blockchains will play in the Age of AI, the ultimate use case for the subspace protocol is now much more clear. Our network will serve as the backbone of a global safety layer for AI. In order for us to be successful in this endeavor, we will need to make several changes to our project as we prepare for the imminent launch of our network. Perhaps the most significant change is that we have chosen a new name for the project. Recognizing that subspace is a technology, what we need is a name that captures the value provided by this technology in a clear and meaningful way. That name is *Autonomys*. From this day forward our project will be known as Autonomys, the first network for both humans and AI. The subspace protocol will remain a core component of the Autonomys technology stack, but we must recognize that subspace is not what we are, instead it is what will allow us to make an impact on the world. What follows is a description of how Autonomys will make that impact. # Intro to AI3.0 & the Age of Autonomy ## Background The rapid advancement of artificial intelligence (AI) technologies is ushering in a new era of socioeconomic transformation. Recent breakthroughs in machine learning (ML), particularly in [deep learning](https://academy.autonomys.xyz/autonomys-vision/www.dx.doi.org/10.1038/nature14539) and natural language processing, have led to AI systems capable of performing tasks once thought to be the exclusive domain of human intelligence. This progress has sparked debates about the future of work, with some experts predicting [widespread job displacement](https://academy.autonomys.xyz/autonomys-vision/www.doi.org/10.1016/j.techfore.2016.08.019), and others envisioning new forms of [human-AI collaboration](https://books.google.co.uk/books/about/The_Second_Machine_Age_Work_Progress_and.html). Concurrently, the rise of [blockchain technology](https://doi.org/10.1109/BigDataCongress.2017.85) has introduced novel paradigms for decentralized systems and digital identity. These technological developments have occurred against a backdrop of growing [concerns](https://books.google.co.uk/books/about/Weapons_of_Math_Destruction.html) about data privacy, algorithmic bias, and the concentration of AI capabilities in the hands of a few large corporations. As we approach the potential development of Artificial General Intelligence (AGI) and Artificial [Superintelligence](https://books.google.co.uk/books/about/Superintelligence.html) (ASI)—when AI reach and then exceed human intelligence—it becomes imperative to establish frameworks that ensure AI systems align with human values and preserve [human autonomy](https://books.google.co.uk/books/about/Human_Compatible.html) in an increasingly automated world. The Autonomys Network proposes and seeks to implement a new paradigm of *radical autonomy*, or absolute digital self-governance. ## **AI3.0** What do we mean when we say Autonomys is the *Foundation Layer for AI3.0*? At Autonomys (pronounced *autonomous*), we contend that the evolution of AI can be categorized into three broad phases, each characterized by a unique relationship between humans, decentralization and AI: * **AI1.0 | Centralized ML**: Deep learning becomes widespread as developers are able to build models with the likes of TensorFlow and PyTorch running on cloud computing provided by Big Tech. Humans are primarily passive consumers of AI technologies, interacting with narrow, rule-based systems designed for specific tasks. * **AI2.0 | Centralized Generative AI**: Large language models (LLMs), such as ChatGPT, Gemini and Claude, emerge alongside other Generative AI technologies built by Big Tech. Humans are offered more interactive AI experiences, albeit still through platforms controlled and deployed by centralized entities. * **AI3.0 | Decentralized Human-centric AI**: Open, accessible and collaborative web3-enabled AI model, app and agent development and deployment. Decentralization ensures a transparent, composable and secure ecosystem where innovation thrives. Humans not only interact with AI, but customize, train and deploy their own highly personalized Autonomys agents to act on their behalf, blurring the boundary between AI creator and consumer. The Age of Autonomy is the culmination of this paradigm. ## The Age of Autonomy Throughout the history of technological development, humanity has consistently striven for the same fundamental needs to be fulfilled: *safety*, including both physical and resource security; *connection*, be it physical or emotional, to fellow humans or cultural collectives; and *prosperity*, through self-improvement and socioeconomic development. Many experts have discussed AI’s impact on human [safety](https://books.google.co.uk/books?id=8vm0DwAAQBAJ\&dq=), [connection](https://danielmiessler.com/p/ai-predictable-path-7-components-2024) and [prosperity](https://books.google.co.uk/books?id=PMBUAgAAQBAJ). Autonomys is using these three fundamental human desires as guiding principles to propose a human-centric vision of a post-AI-revolution future. In today’s world, one’s safety and prosperity are mediated largely by one’s access to economic resources. As job security becomes progressively more [threatened](https://doi.org/10.1016/j.techfore.2016.08.019) by the advent of sophisticated AI, we should evolve our contemporary economic systems with continued human relevance and agency in mind. This can be achieved through widening global access to permissionless incentivized contribution networks, and by augmenting human capabilities with personal AI agents that seamlessly interact and collaborate in a verifiable way—all free of centralized control. The trajectory of AI development is trending towards the training and running of smaller, specialized AI models on personal edge devices. When integrated into every action taken on a [personal device](https://www.apple.com/apple-intelligence/), these AI will have the context of all knowledge about the device’s owner, including past and present interactions with other people or services; personal preferences in entertainment, food, clothing and partners; health metrics; financial statements; political allegiances; and everything else that has ever gone through the device. Coupling access to complete contextual data with agentic capabilities transforms personal AI into personal agents that can represent you online and act on your behalf—booking medical visits and vacations, ordering groceries, coordinating meetings, managing money, or participating in governance. Crucially, personal agents will be able to analyze and filter the endless information streams around us—insurmountable for a single person to process—aiding in our decision-making. It is prudent to estimate the emergence of at least as many agents online as there are smartphones. Practically, we can expect each person and business to have multiple specialized AI representatives. This global mesh of billions of agents will communicate and exchange funds with each other online and with service providers via agent-specific permissioned actions. Humans and agents will need to be able to verify whether the AI they are interacting with within this autonomous agent economy are truthfully representing themselves as agents of particular [individuals or organizations](https://academy.autonomys.xyz/autonomys-solutions/autoid). The Autonomys-facilitated agent economy will foster a rich ecosystem of human and AI collaboration. Autonomys’ development platform will provide cutting-edge tools for individuals and organizations to train and deploy agents, acquire highly valuable technological skills, and amplify their potential. Autonomys agents will be able to exchange mutual authorizations via blockchain to provide real-world goods and services, while humans maintain oversight of and control over them. This dynamic creates new avenues for entrepreneurship and value generation as individuals and organizations leverage AI capabilities to augment their own skills and offerings. Autonomys’ vision preserves humanity’s economic relevance by emphasizing domains where the unique human capacity for creativity, emotional intelligence, and complex problem-solving has not been replicated by AI. In contrast to predicted futures populated by a universal basic income [(UBI)-dependent humanity](https://moores.samaltman.com/) subject to a diminished human agency and economic relevance, Autonomys champions radical autonomy through incentivized participation and contribution to a self-sustaining ecosystem, inspired by Ethereum’s pioneering model. We recognize human potential as a dynamic force that can be continually expanded through education, technological integration, and innovative socioeconomic systems. By empowering individuals with self-sovereign digital identities, control over their data assets, and tools for safe AI collaboration, Autonomys is forging a future where humans and AI coexist productively and harmoniously. This new paradigm not only preserves human economic relevance but amplifies our collective potential, ushering in an era of unprecedented innovation, creativity, and shared prosperity. ## Autonomys AI3.0 Stack The Autonomys Network serves as the technological infrastructure for this paradigm shift, providing a verticalized decentralized AI stack encompassing:

Autonomys AI3.0 Stack

* [***dApp/Agent Layer***](/autonomys-vision/use-cases)***:*** facilitating the development and deployment of super dApps (AI-powered dApps) and Autonomys Agents ([Auto ID](/auto-suite/auto-id)-integrated on-chain agents) for verifiable digital interaction. * [***Execution/Domain Layer***](/autonomys-network/decoupled-execution)***:*** secure, scalable distributed compute for AI training, inference and agentic workflows. * [***Consensus Layer***](/autonomys-network/consensus)***:*** verifiable decentralized sequencing and transaction validation for shared security. * [***Storage Layer***](/autonomys-network/distributed-storage-network)***:*** multi-layer distributed storage ensures data integrity and permanent availability—crucial for storing vast amounts of AI data. Utilizing the [Subspace Protocol](/autonomys-network/introduction), with its innovative hybrid [Proof-of-Archival-Storage (PoAS)](/autonomys-network/consensus/proof-of-archival-storage)/[Proof-of-Time (PoT)](/autonomys-network/consensus/proof-of-time)/[Nominated Proof-of-Stake (NPoS)](/autonomys-network/decoupled-execution/staking) consensus mechanism, our decentralized physical infrastructure network (DePIN) incentivizes active participation through the permissionless contribution of any amount of storage space or compute, or staking of any amount of tokens, permitting unprecedented accessibility. # Use-Cases Demos, examples and suggested applications ## Demos {% embed url="" %} Argu-mint Demo {% endembed %} {% embed url="" %} Autonomys Auto Chain Agent Demo {% endembed %} {% embed url="\_" %} RAG and Private Compute on Autonomys DSN Demo {% endembed %} ## Contents A. [Future-Proofing Storage for AI3.0](#a.-future-proofing-storage-for-ai3.0) B. [Content Provenance and Data Sovereignty](#b.-content-provenance-and-data-sovereignty) C. [Digital Identity](#c.-digital-identity) D. [Proof-of-Personhood](#d.-proof-of-personhood) E. [Decentralized Reputation Systems](#e.-decentralized-reputation-systems) F. [Decentralized Learning and Proof-of-Training](#f.-decentralized-learning-and-proof-of-training) G. [Data Contribution and Compensation](#g.-data-contribution-and-compensation) H. [Agent Infrastructure and Multi-Agent Systems](#h.-agent-infrastructure-and-multi-agent-systems) I. [Agent Identities](#i.-agent-identities) J. [Open Collective Intelligence and the Global DAO Mesh](#j.-open-collective-intelligence-and-the-global-dao-mesh) K. [Verifiable AI3.0 Infrastructure as a Public Good](#k.-verifiable-ai3.0-infrastructure-as-a-public-good) ## A. Future-Proofing Storage for AI3.0 The advent of AI3.0 brings with it an unprecedented demand for vast, permanent decentralized storage capable of rapid data retrieval. As AI systems become more sophisticated and personalized, they require access to enormous datasets for training, fine-tuning, and real-time decision-making. Traditional centralized storage systems are ill-equipped to handle the scalability, security and accessibility requirements of this new paradigm. Decentralized storage solutions offer several key advantages: ensuring data integrity and availability through redundancy; mitigating single points of failure; and allowing for more equitable distribution of resources. Moreover, the permanence of data storage is crucial for maintaining historical records, enabling long-term learning, and supporting accountability in AI decision-making processes. Rapid data retrieval is equally essential, as AI3.0 agents must be able to access relevant information swiftly to provide real-time responses and make informed decisions. This combination of vast capacity, permanence, decentralization, and speed is fundamental to realizing the full potential of AI3.0—where personalized Autonomys agents operate efficiently and verifiably at scale. Autonomys addresses this growing demand via our super-fast, hyper-scalable, permanent [distributed storage network (DSN)](/autonomys-network/distributed-storage-network) and content-delivery network (CDN) supported by multiple reliability layers; secured by PoAS consensus; and served by thousands of easy-to-setup nodes worldwide. At the core of the Autonomys economy is the concept of data sovereignty, enabled by our vast decentralized storage and systems for content contribution, provenance, and compensation. This revolutionary approach to understanding and managing personal information and intellectual property—where individuals retain control over their data assets and can opt to monetize them for AI training and optimization purposes—pioneers a novel economic model where humans may choose to share their personal data and receive fair compensation for the value their data provides in enhancing AI systems, rather than having their information exploited without remuneration, as is currently the case. ## B. Content Provenance and Data Sovereignty Data sovereignty—the ability of individuals to control and maintain authority over their personal data and digital presence—is crucial in an era where sensitive data is frequently exploited by criminal actors and centralized entities. Data sovereignty cannot be achieved without a way to establish ownership and provenance of data in a verifiable way. Cryptographically linking digital content with its creator’s authenticated identity establishes an [immutable record of origin](http://usenix.org/event/fast09/tech/full%20papers/hasan/hasan.pdf) and subsequent modifications. Such a system empowers users with granular control over their data sharing preferences and provides a robust framework for verifying the authenticity of digital assets. It also offers a potential solution to the challenges posed by synthetic media, allowing recipients to discern between genuine and [artificially generated content](http://doi.org/10.22215/timreview/1282). Furthermore, as AI systems continue to evolve and generate increasingly sophisticated outputs, the ability to trace the lineage of training data and resultant content is becoming [increasingly important](https://arxiv.org/abs/2004.07213). ## C. Digital Identity Autonomys’ secure protocol for the provision of decentralized digital identities—Autonomys Identity ([Auto ID](/auto-suite/auto-id))—simultaneously allows for the authentication of AI-generated content and permissioning of agentic actions. Utilizing advanced cryptographic techniques, our robust self-sovereign identity (SSI) framework (deployed as a registered runtime on Autonomys’ domain layer) enables individuals to verify their identity without resorting to invasive biometric procedures. This foundational of digital trust is crucial for facilitating economic collaboration between humans and AI. Key properties of the Auto ID system include: * *Self-sovereignty:* Users maintain complete control over their digital identity, with autonomy in information-sharing decisions via a combination of encryption, zero-knowledge and verifiable credentials. * *Verifiability:* Cryptographic proofs ensure the authenticity of claims without compromising personal information. * *Universality:* Auto IDs can be issued to any entity, human or artificial, enabling a common identity standard across the digital ecosystem. * *Versatility:* The Auto ID framework supports identity self-issuance, issuance by another entity, and co-issuance by multiple entities. * *Interoperability:* Auto ID is designed for seamless integration with existing identity systems such as [X.509](https://www.rfc-editor.org/rfc/rfc5280) and [Decentralized Identifiers](https://w3c.github.io/did-core/). Auto ID plays a crucial role in establishing content provenance and ensuring data sovereignty. After obtaining an Auto ID, entities can digitally sign the content they produce, establishing a verifiable and tamper-proof record of authenticity and provenance for data, linked with their Auto ID. This is particularly important as the line between human-created and machine-generated content becomes increasingly blurred. Cryptographically linking digital content with its creator’s authenticated identity establishes an immutable record of origin and subsequent modifications. Such a system empowers users with granular control over their data sharing preferences and provides a robust framework for verifying the authenticity of digital assets. It also offers a potential solution to the challenges posed by synthetic media, allowing recipients to discern between genuine and artificially generated content. Autonomys also offers the ability to attach cryptographic identity claims to an Auto ID via verifiable credentials. For example, an individual may attach a verifiable credential to their Auto ID showing they have a valid diploma, and later utilize that claim when a diploma is required. ## D. Proof-of-Personhood As we transition into an agent-integrated world, the ability to distinguish between humans and artificial entities becomes increasingly crucial. [Auto ID](/auto-suite/auto-id) implements proof-of-personhood (PoP) via our composable, probabilistic PoP protocol [Auto Score](/auto-suite/auto-id/auto-score). This system is designed to address the growing need for verifiable human identity in digital spaces, particularly in scenarios where AI agents and humans interact seamlessly. A strong PoP system is important in the AI3.0 era for several reasons: * *Preventing AI Impersonation:* As AI becomes more sophisticated, the risk of AI systems impersonating humans increases. A strong PoP system helps maintain the integrity of human-to-human interactions in digital spaces. * *Ensuring Fair Resource Distribution:* In a world where AI agents could potentially overwhelm systems, PoP ensures that resources and opportunities are fairly distributed among genuine human users. * *Maintaining Democratic Processes:* For online voting or governance systems, PoP is crucial to prevent manipulation by automated systems or sock puppet accounts. * *Preserving Human-Centric Economies:* As AI agents become more prevalent in economic systems, PoP helps maintain spaces for human economic activity and prevents AI from dominating marketplaces. * *Ethical AI Development:* PoP systems can help ensure that AI training data comes from verified human sources, promoting more ethical and representative AI development. [Auto Score](/auto-suite/auto-id/auto-score) leverages pre-existing evidence of personhood and zero-knowledge proofs (ZKPs) to generate privacy preserving, verifiable credentials that combine to offer a probabilistic proof-of-personhood score. Supporting ZKP-secured e-passport verification as a primary personhood factor, users need only scan the NFC chip in their passport and prove the correctness of the signature in a ZK-proof to achieve a high Auto Score. When combined with liveness checks, ZK-passport tech presents the strongest evidence of unique personhood and contributes to the highest possible Auto Score. For applications that do not require government-grade identification, and users who do not possess or want to associate one with their Auto ID, Auto Score accepts alternative personhood factors. These include credit cards, social media accounts, and participation in decentralized networks. As a probabilistic PoP protocol, Auto Score functions by aggregating and evaluating various pieces of evidence supporting an entity’s claim to personhood. Each piece of evidence is assigned a weight based on its reliability and difficulty to forge. This evidence is shared utilizing ZKPs, allowing users to selectively share specific details, such as age of nationality, or prove their possession of credentials without revealing the underlying data to a verifier. Autonomys then calculates a composite score representing the probability of the user being a unique human using these weighted pieces of evidence. This score updates as users add or remove credentials, or as their digital interactions evolve, providing a dynamic measure of digital personhood. Auto Score possesses the following characteristics: * *Probabilisticity:* Provides a nuanced measure of person hood rather than a binary determination, reflecting the complex nature of identity in the digital age. * *Privacy-preservation:* Leverages ZKPs and advanced cryptographic techniques to enable users to demonstrate their personhood without revealing sensitive personally identifiable information (PII), crucial in an era of increasing data breaches and privacy concerns. * *Dynamism:* An entity’s personhood probability score updates as they interact with the Autonomys ecosystem, reflecting their ongoing participation and contribution, and adapting to the evolving nature of digital identity. * *Composability:* Entities can build their digital identity incrementally by combining various types of evidence, allowing for a more comprehensive and nuanced representation of personhood. * *Flexibility:* Entities have full control over which components to include in their Autonomys PoP, empowering users to manage their digital identity according to their preferences and needs. * *Interoperability:* Integrates with current and emerging identity systems, and existing personhood evidence from web2 or web3 accounts, utilizing [TLS](https://tlsnotary.org/TLSNotary.pdf) [ZK](https://docsend.com/view/5wdg66beu7m95jf3)-[proofs](https://drive.google.com/file/d/1wmfdtIGPaN9uJBI1DHqN903tP9c%20aTG2/view) for rapid verification, improving user experience and bridging the gap between different digital ecosystems. A composable, privacy-preserving PoP protocol is integral to the building of a novel digital identity system for an AI integrated world. This approach aims to provide a familiar user experience while maintaining absolute privacy and anonymity. Using multiple, pre-existing personhood factors allows Auto Score to circumvent issues of accessibility and centralization present in [current biometric PoP protocols](https://vitalik.eth.limo/general/2023/07/24/biometric.html), and ensures that every person has the ability to autonomously demonstrate their humanity unimpeded by borders and institutions. By approaching proof-of-personhood as a composable and probabilistic measure, Autonomys offers a more nuanced and adaptable solution to the challenge of verifying human identity in digital spaces. This system preserves individual privacy while providing sufficient assurance of personhood to enable trust in human-AI interactions and decentralized governance processes. Auto ID and Auto Score represent a vital contribution to the development of the autonomous economy by providing it with an accessible, standardized framework for digital identity and data provenance. This will help facilitate verifiable human AI interaction, enable privacy-conscious verification, establish metrics of trust, and ensure traceability, promoting digital safety and inclusion in an increasingly AI-driven world. ## E. Decentralized Reputation Systems As components of the Autonomys Network, Auto ID and Auto Score provide strong foundations on which to build a robust decentralized reputation system (DRS) that would allow participants to make anonymous yet verifiable assertions about their own [reputation](https://eprint.iacr.org/2020/761.pdf). An Auto ID-based DRS would offer users the ability to selectively share reputation claims, such as a credit score or developer reputation, in a way untraceable to their primary ID, while preserving Sybil-resistance and security against manipulation, including whitewashing and denial. Such a robust DRS would allow novel applications to be built on Autonomys—from peer-to-peer commerce and gig economy platforms to protocols for decentralized lending, crowdfunding, and collaborative research. ## F. Decentralized Learning and Proof-of-Training Decentralized learning approaches aim to train machine learning models across multiple devices or nodes without relying on centralized data aggregation, thereby preserving privacy and data ownership. The Autonomys Network’s underlying Subspace Protocol is uniquely positioned to facilitate decentralized learning as it addresses several challenges that impede the practical implementation of decentralized AI storage/compute-sharing DePIN. [Li (2023)](https://doi.org/10.48550/arXiv.2307.07066) identifies the significant state storage and bandwidth requirements of ML as the primary barriers to the mainstream usability of existing systems. The issues of state bloat and history growth beyond the capacity of any single node are addressed in our novel Proof-of-Archival Storage (PoAS) consensus mechanism and distributed storage network (DSN) design that stores only partial state and partial history on each individual node. The bandwidth required to support the movement of large amounts of training data and models through our network will be achieved—without hindering decentralization—following the implementation of our scalability roadmap. Li also determines the ability to dynamically adjust work load based on demand for AI jobs in a way decoupled from transaction validation and consistent block time requirements to be a highly desirable feature of a deAI utility network. This is achievable through Autonomys’ decoupled execution (DecEx) framework, which gives domains—independent execution environments—the freedom to set any particular hardware requirements for nodes running execution on that domain, and only commit state transitions when there is demand for the domain’s resources. This architecture allows for efficient allocation of computational resources for decentralized learning tasks while maintaining the blockchain’s normal operation and other network activities. The Proof-of-Training (AI-PoT—to distinguish it from proof-of-time (PoT)) protocol [described by Li](https://doi.org/10.48550/arXiv.2307.07066) could be adapted to function as a specialized domain on the Autonomys Network. The AI-PoT domain would manage the training processes, including task distribution, model validation, and reward allocation, while benefiting from the underlying security and scalability of the Autonomys Network. The operators of this domain would act as service providers, validators, and verifiers, with their roles and responsibilities defined by the Proof-of-Training protocol. The workflow described in [Li (2023)](https://doi.org/10.48550/arXiv.2307.07066) could be run on Autonomys’ domains framework as follows: 1. *Client Submission:* A client submits an order containing model specifications, training data, and payment information via a transaction to the AI-PoT domain. 2. *Order Processing:* The order transaction is picked into the domain mempool and eventually added to a bundle, which is then submitted to the consensus chain for farmers to include in a block. Once in a block, the order becomes available for service providers (a selected subset of staked domain operators) to fetch. 3. *Model Training:* Service providers compete to train the best model based on the order specifications. 4. *Claim Submission:* As service providers generate improved models, they submit claims containing model signatures to the network. 5. *Model Revelation:* After the training period ends, operators reveal the full models corresponding to their submitted signatures. 6. *Validation Phase:* Validators (the rest of the operators on the AI-PoT domain) evaluate the revealed models using the specified validation function and test data before broadcasting validation messages. 7. *Verification:* Any honest operator on the domain can challenge any suspicious validations, adding an extra layer of security. 8. *Challenge Period:* A time window allows for potential challenges to be resolved. 9. *Finalization:* The network finalizes the results, determining the best model and associated rewards within the challenge period. 10. *Payment Distribution:* As soon as the challenge period has passed, the payments are distributed to the winning service provider and validators. 11. *Result Retrieval:* The client can retrieve the best model from the network. The Autonomys Network’s native token could be utilized for staking and rewards within an AI-PoT domain, creating a robust economic incentive structure for honest participation. By integrating AI-PoT as a domain, the Autonomys Network will be able to offer a future-proof solution for distributed AI training, capable of adapting to new AI models and training methodologies without requiring changes to the core protocol. Autonomys’ flexible domain framework also allows for the implementation of other common decentralized learning paradigms, including federated and swarm learning, and is thus adaptable to an application’s specific needs. To enhance the security and privacy of the federated learning process, Autonomys plans to incorporate secure multi-party computation (MPC), differential privacy, and other [advanced cryptographic techniques](https://doi.org/10.1007/s00287-019-01205-x) into our network. These methods allow for the aggregation of model updates without exposing individual user data, protecting user privacy, while enabling valuable contribution to AI development. Decentralized learning systems integrated with Auto ID would benefit from a persistent DRS for compute providers, ML engineers, and agent developers that testifies to the quality of their previous contributions, trained models and built applications. ## G. Data Contribution and Compensation Consumer devices, industrial hardware and other electronic equipment generate and record vast amounts of information about the world which gets discarded after expending its usefulness to the device owner. In some cases, the data is retained by the device manufacturer in a manner opaque to the device owner. Since AI models have already virtually exhausted the world’s existing Internet-accessible data sources, the often real-time data provided by Internet-of-Things (IoT)-enabled hardware like these is the next step in data acquisition for machine learning. The Auto ID framework can be leveraged to enable users to participate in decentralized learning initiatives (such as federated learning and swarm learning) by contributing their data to machine learning models, while maintaining privacy and control over their personal information. Decentralized learning allows for model training on distributed datasets without the need for centralized data storage, thereby mitigating risks associated with data breaches and unauthorized access. The integration of decentralized learning with blockchain-based identity and compensation mechanisms represents a significant step towards a more equitable and decentralized AI ecosystem. Moreover, it creates a new paradigm for data ownership and monetization, where individuals can directly benefit from the value their data creates in AI systems. This approach aligns with the principles of [data sovereignty](https://www.aeaweb.org/articles?id=10.1257/pandp.20181003) and deAI, and addresses growing concerns about data privacy and the [centralization](https://books.google.co.uk/books/about/Who_Owns_the_Future.html?id=obDsAgAAQBAJ\&redir_esc=y) of AI development. To incentivize high-quality data contribution and ensure fair compensation, the Autonomys Network will implement a [data valuation](https://doi.org/10.48550/arXiv.2305.01657) framework inspired by [Shapley-value-based](https://proceedings.mlr.press/v97/ghorbani19c.html) methods, which quantifies individual contributions to the decentralized learning process. It considers multiple factors in its valuation algorithm, including data quality, uniqueness, relevance to the specific model being trained, and the impact on model performance improvements. This approach aims to accurately reflect the true value of each user’s data contribution, moving beyond simplistic metrics such as data volume. The valuation process will be complemented by a compensation mechanism that utilizes the Autonomys Network’s native token. The implementation of such specialized mechanisms naturally maps onto Autonomys’ domain layer of decoupled execution environments, allowing for independent development and upgradability without burdening the core protocol. This domain will automatically remunerate users whenever their data is accessed or utilized in model training or inference. Given the large number of individual users and data points the system will have to process during every training and inference request, and the number of payouts this will entail, we will employ several optimizations. These include accruing compensation in a smart contract and letting users initiate claims for payouts. All the accrual and claim records on the domain will be anchored and archived within the global history of the chain, ensuring transparency and immutability in recording data usage and corresponding compensation. The system may also implement a dynamic pricing model that adjusts compensation based on market demand for specific types of data, creating a more efficient data marketplace. As an additional benefit, this approach could potentially lead to more diverse and representative datasets, addressing issues of bias in AI systems that often arise from limited or homogeneous training data.

Data Contribution and Compensation

## H. Agent Infrastructure and Multi-Agent Systems AI models capable of autonomously interacting with their environment (agents) operating in a distributed environment can collaborate with each other on complex tasks to achieve shared goals as part of multi-agent systems (MAS). The emergent AI agent technology ecosystem, exemplified by projects such as [BabyAGI](https://github.com/yoheinakajima/babyagi), [AutoGPT](https://github.com/Significant-Gravitas/AutoGPT), and [GPT-Engineer](https://github.com/gpt-engineer-org/gpt-engineer), has demonstrated the immense potential of autonomous AI systems. These projects showcase the ability of AI agents to perform complex tasks, engage in goal-oriented behavior, and even recursively improve their own capabilities. At their core, they are based on simple, yet powerful techniques—chains of prompts and responses that decompose large tasks into independent sub-tasks that execute autonomously in a multi-step process before self-validating the output. Frameworks like [LangChain](https://github.com/langchain-ai) have extended these agentic capabilities by providing API calls which allow local agents to interact with the “outside” world. [Chainlink Functions](https://chain.link/functions) have made web2 APIs composable with blockchain rails and web3 smart contracts. The success of these initiatives has ignited widespread interest in agentics, pointing to a future where AI agents play an increasingly important role in various applications. If each individual and business entity is to have multiple agents acting on their behalf, it is imperative we build the infrastructure to support an economy of billions of these agents. Infrastructure for agent deployment differ in their hosting structure and location and in their method of interaction with external service providers and other agents. On the hosting layer, agents can be categorized into specialized agents—that can run exclusively on edge devices using smaller models—and generalized agents—that require high-density GPUs and large amounts of RAM. Generalized agents utilize large frontier models for task decomposition, prioritization and result validation, allowing them more advanced reasoning levels compared with specialized agents, which use smaller, task-specific models. However, specialized agents offer advantages in terms of lower latency, reduced power consumption, and improved privacy due to their ability to operate locally on edge devices. It is thus prudent to assume that there will be a significant heterogeneity of model sizes, hardware requirements and capabilities in use. The Autonomys Network is interoperable with these various platforms owing to its common composable interface and network between domains. Agents that require hardware beyond the self-hosting capabilities of a single user or organization can be programmed to run continuously or on-demand via specialized Autonomys compute-sharing domains. On-chain agents (Autonomys agents) that are in constant high demand may benefit from being deployed on their own domain with specific hardware requirements for operators of that domain. In addition, agents need digital storage integration for their memory and knowledge base. The Autonomys Network’s decentralized storage layer is able to provide this data availability. The most effective agentic decision-making is achieved when agents have access to data outside of their training set, such as information about events that occurred after the training was complete, specialized domain knowledge, or the personal data of the user. Financial trading agents, for example, greatly benefit from access to real-time news from around the world, as do many other applications. The process of factual data retrieval from external sources to enhance the reliability of generative AI outputs is known as retrieval-augmented generation (RAG). Autonomys agents can perform RAG by tapping into the sovereign data economy described in Data Contribution and Compensation to access data (stored in archival storage) being offered in the marketplace, and compensating the creators for its use (in our native token). On the higher levels of the stack, Autonomys agents perform tasks on their users’ behalf in accordance with user intents. This entails users delegating authority to them to carry out certain permitted activities, including managing user authentication and authorization while interacting with external services, and accessing their user’s financial resources and means of transferring them to pay for goods and services. Every Autonomys agent interacting with the network obtains an identity at deployment, registered through Auto ID, providing verifiable and tamper-resistant agent identities. These IDs may be issued by individuals or organizations with metadata about the agent’s purpose and capabilities. Humans, organizations and agents on Autonomys can define hyper-specific permissions for agentic interaction with Auto ID, enhancing security and privacy. Possession of an Auto ID by an agent permits it access to the economic system of the network, allowing it to manage a balance, spend funds and receive payments. All identity claims, authorization events, and agent interactions are provable on-chain, providing a transparent and immutable audit log facilitating accountability and post-hoc analysis. As a unified system for all entities on-chain, Auto ID simplifies the invocation of registered agents for both users and other agents. This agent invocation mechanism is augmented with a distributed reputation system for optimized reliability and performance. Agent-to-agent communication requires a common interface to facilitate seamless interaction and collaboration on complex tasks, such as organizing a conference, illustrated below. Autonomys’ unified identity framework unlocks composability for agents and cooperation for effective task execution through the advent of multi-agent systems. Each agent can expose endpoints within a shared interface that allow other entities to discover the list of services it provides and actions it is authorized to perform.

Example of a MAS for coordinating the organization of a conference with a catering service and a merchandise stand:
1) Alice intends to book a venue for a conference. She authorizes her personal agent to manage her calendar and represent her in specific interactions by signing verifiable credentials (VCs), allowing it to share information with other agents.
2) Alice’s agent contacts those of her colleagues, Bob and Carol. Each agent exchanges VCs to verify that they are authorized representatives of their users.
3) Each agent exchanges their user’s calendar availability to align their schedules, and confirms the requirements, budget and technical setup for the conference, the merchandise to be distributed and each person’s dietary restrictions.
4) Alice’s agent initiates a dialogue with the conference venue’s customer service agent. Both agents exchange their VCs to ensure they are authorized to make bookings and share sensitive information.
5) The venue’s agent verifies availability and confirms the preferred time for the conference. Alice’s agent communicates their dietary restrictions to ensure the venue’s catering can accommodate them. They discuss the technical setup and space needed for merchandise distribution before negotiating a price.
6) The venue’s agent coordinates with the catering service agent to ensure all dietary restrictions are met.
7) The agents of the merchandise suppliers are contacted to confirm the price, design, delivery and setup of the conference materials and products.
8) All agents use their edit-permission VCs to update their users’ respective calendars with the relevant information. The venue’s booking system is updated with the reservation and all specified requirements.

## I. Agent Identities Autonomous agents will operate independently and on behalf of human entities. This paradigm shift necessitates robust mechanisms for accountability. Public key infrastructure (PKI) presents a natural solution, as it is built fundamentally on chains of trust, which establish a verifiable and transparent lineage of trust relationships, ensuring each entity in the chain can be held accountable for their actions, and any breaches can be easily traced. We propose the development of an enhanced PKI system, augmented with additional identity mechanisms, to facilitate the transition to a secure era of human-agent collaboration. Our proposed Autonomys PKI derives the Auto IDs of any Autonomys agents users build from the Auto IDs of the individual(s) and/or organization(s) that built them. The system provides a secure and transparent mechanism for authorizing the actions of agents within the Autonomys ecosystem via the granting and revoking of granular permissions. This ensures that these AI systems operate within the bounds of their predetermined roles. Permissioned delegation of authority is crucial in a world where digital employee and personal assistant agents make important decisions and perform vital tasks for both organizations and individuals. Key features of agent Auto IDs include: * *Traceability:* Blockchain tech enables the tracking of agent actions and decisions, supporting auditability and safety in AI development, deployment and alignment. * *Delegation:* Users can securely delegate authority to AI agents, defining their roles and permissions. * *Accountability:* The system maintains a clear chain of responsibility from the agent back to its human or organizational creator. In summary, by enabling users to delegate authority to AI agents; trace the lineage and behavior of agentic systems for safety and regulatory compliance; maintain accountability in digital interactions; and authenticate AI-generated content, Auto ID facilitates much more secure and equitable interaction between humans and AI, establishing a foundation of trust crucial for the autonomous machine economy. ## J. Open Collective Intelligence and the Global DAO Mesh Recent developments in [decentralized autonomous organization (DAO)](https://doi.org/10.1080/13691066.2022.2116797) technology have showcased the numerous avenues of potential they provide for the future of collaborative decision-making and resource allocation in this new economy. Building upon these foundations, we propose a novel framework that leverages the power of collective intelligence through a network of Auto DAOs interconnected in a Global DAO Mesh. Collective intelligence—a form of intelligence emerging from collaboration between many individuals—is already being harnessed for effective decision-making and governance by DAOs. Auto DAOs—smaller, specialized DAOs, composed of both human and AI members, deployed on the Autonomys Network—will demonstrate the efficacy of their collective intelligence by managing decentralized projects. Examples include web3 initiatives, investment funds, and research and development for open-source software. When these Auto DAOs are integrated into a larger, interconnected network—the Global DAO Mesh—a more effective and efficient system of collective intelligence emerges. Autonomys envisions the Global DAO Mesh serving as the decentralized framework for open collective intelligence (OCI)—a more humanistic, albeit AI-augmented, alternative to artificial general intelligence (AGI). OCI operates on the principle of distributed problem-solving, where large, complex challenges are decomposed into smaller, more manageable tasks. These subtasks are then allocated to different Auto DAOs based on their specialized knowledge domains and vested interests in the issue at hand. The process of collective problem-solving via OCI within the Global DAO Mesh can be described as follows: 1. *Problem Decomposition:* Complex issues are broken down into independent components. 2. *Task Allocation:* Subtasks are distributed to relevant Auto DAOs within the mesh. 3. *Parallel Processing:* The human and AI members of each Auto DAO collaboratively address its assigned component. 4. *Solution Aggregation:* The Global DAO Mesh aggregates the solutions from individual Auto DAOs (potentially via a round of consensus with a weighted function representing the relative expertise of each DAO). 5. *Recombination and Synthesis:* The aggregated solutions are recombined to form a cohesive resolution to the original, complex problem. Inspired by [mixture of experts networks (MoE)](https://doi.org/10.48550/arXiv.1312.4314), all steps in the process can be mediated via an agentic AI system that understands the necessary context on existing DAOs, their public members’ expertise, and the prior participation records of both. This methodology creates a networked intelligence that is both decentralized and scalable, capable of addressing challenges of a magnitude not feasible for individual human or DAO entities. Drawing parallels with the [Allora Network](https://whitepaper.assets.allora.network/whitepaper.pdf), our proposed system similarly leverages decentralized machine intelligence. However, while Allora focuses on a self-improving AI network, the Global DAO Mesh’s OCI emphasizes the synergy between human and AI intelligence within a decentralized governance structure. Autonomys’ Global DAO Mesh thus represents a significant advancement in collective problem-solving capabilities. The Global DAO Mesh distinguishes itself via several key advantages: * *Hybrid Intelligence:* Combines the strengths of both human intuition and AI computational power. * *Specialization:* Leverages the unique expertise of different Auto DAOs for optimal problem-solving. * *Decentralization:* Ensures no single point of failure and promotes a truly distributed decision-making process. * *Scalability:* Allows for the tackling of increasingly complex problems by distributing the workload across multiple Auto DAOs. Important research directions to ensure an ethically aligned global decision-making system include optimizing task allocation algorithms to ensure fair representation, developing robust consensus mechanisms for solution aggregation, and exploring the potential for emergent behaviors within the Global DAO Mesh. ## K. Verifiable AI3.0 Infrastructure as a Public Good The provision of a public good infrastructure for accessible, verifiable AI is of paramount importance in our rapidly evolving technological landscape. As highlighted by [Korinek and Stiglitz (2019)](https://nber.org/system/files/chapters/c14018/c14018.pdf), the advancement of AI technologies has significant implications for income distribution and employment. Equal access to AI is crucial if we are to maintain economic relevance and reduce the risk of AI-driven inequality. Democratizing AI entails ensuring that the benefits of these technological advancements are more equitably distributed across society. In pursuit of this goal, Autonomys is committed to establishing infrastructure that offers equal access to verifiable AI agents, tooling and resources as a public good. A key component of this digital public infrastructure is Autonomys’ dedicated directory for the decentralized storage, indexing and distribution of open-source AI data within our extensive, immutable, permanent DSN. The primary objective of our decentralized open-source AI directory is to securely store and make freely available a wide range of valuable AI resources, including: * Open-source AI models * Publicly available training datasets * Fine-tuning datasets At the same time as providing a robust, permissionless, decentralized solution for building and deploying AI models and agents, the Autonomys Network preserves these critical AI assets, ensuring they remain accessible and protected against potential censorship or removal in perpetuity. # Introduction From the Subspace Protocol to the Autonomys Network {% embed url="" %} At its core, the Autonomys Network implements [Subspace](https://cdn.prod.website-files.com/61526a2af87a54e565b0ae92/617759c00edd0e3bd279aa29_Subspace_%20A%20solution%20to%20the%20farmer%27s%20dilemma.pdf), a novel storage-based consensus protocol that separates transaction ordering from execution. The Subspace Protocol was designed from the ground up to enable an open and inclusive Internet by: * Providing an energy-efficient and eco-friendly alternative to proof-of-work (PoW), while still allowing for mass participation by ordinary users. * Creating an incentive-compatible permissionless network that encourages and maintains decentralization over the long term. * Scaling network storage and compute capacity proportional to the number of node operators, without sacrificing decentralization or security. * Connecting and enabling interoperability between existing networks. Achieving this vision required an alternative to both resource-intensive PoW mining and permissioned proof-of-stake (PoS)—a cryptographic proof system based on an underlying resource that is already massively distributed and which does not lend itself to special-purpose hardware. Enter [*proof-of-capacity* (PoC)](#user-content-fn-1)[^1], which replaces compute-intensive mining with storage-intensive farming, under the maxim of one-disk-one-vote. Disk-based consensus is an obvious solution as storage hardware consumes negligible electricity, exists in abundance across end-user devices, and has long been commoditized. Subspace uses a longest-chain PoC consensus mechanism based on solid-state drive (SSD) storage. Adhering to Nakamoto’s vision, the blockchain is permissionless but secure, with respect to safety and liveness, as long as honest farmers collectively dedicate more storage than any cooperating group of attacker nodes. In essence, Subspace follows the Ethereum model of a fully programmable, account-based blockchain, which periodically commits to the state of all accounts within the block header. Contrary to many existing PoC protocol designs, Subspace addresses a critical mechanism design challenge—[the farmer’s dilemma](https://cdn.prod.website-files.com/61526a2af87a54e565b0ae92/617759c00edd0e3bd279aa29_Subspace_%20A%20solution%20to%20the%20farmer%27s%20dilemma.pdf)—which poses a significant threat to the decentralization and security of PoC blockchains. Rational farmers are incentivized to allocate all their available storage towards consensus, neglecting the maintenance of [chain state and history](https://bitslog.com/2014/11/03/proof-of-local-blockchain-storage/). In the farmer’s dilemma, this behavior leads to farmers effectively becoming light clients, degrading network security and decentralization. The trend ultimately risks consolidation into large farming pools, centralizing control around pool operators, and reducing the network’s resilience against malicious actors. The farmer’s dilemma also exacerbates the [verifier’s dilemma](https://dx.doi.org/10.1145/2810103.2813659) by raising the opportunity cost of verification. If full nodes do not store the chain history, new nodes must instead rely on altruistic archival nodes or third-party data stores for initial synchronization, resulting in a more centralized network. Subspace circumvents the farmer’s dilemma without sacrificing network security or decentralization as follows: * *To prevent farmers from discarding chain history:* we construct a novel PoC consensus protocol, based on proofs of storage of the blockchain’s history (Proof-of-Archival-Storage), where each farmer stores as many provably unique partial replicas of the chain history as their disk space allows. * *To ensure consensus retains the fairness of one-disk-one-vote:* we make the plotting process more computationally intensive than [Hellman’s time-memory tradeoff](https://ia.cr/2017/893), meaning that augmenting or replacing storage with computation is economically irrational for farmers. * *To ensure chain history remains available:* farmers form a decentralized storage network, which allows chain history to remain fully-recoverable, load-balanced, and efficiently retrievable. * *To relieve farmers of the burden of maintaining the whole state and performing redundant computation:* we apply the classic distributed-systems technique of decoupling consensus and computation. Farmers are then solely responsible for ordering transactions, while a separate class of operator nodes maintains the state and computes the state transitions for each new block. * *To ensure operators (executors) remain accountable for their actions:* we employ a system of staked deposits, verifiable computation, and non-interactive fraud proofs.

Blockchain Data Flow

## Contents This section provides a comprehensive overview of the Autonomys Network, Subspace Protocol, and $AI3: 1. [**Introduction**](/autonomys-network/introduction) 2. [**Terminology**](/autonomys-network/terminology) 3. [**Architecture**](/autonomys-network/architecture) 4. [**Advancing Blockchain**](/autonomys-network/advancing-blockchain) 5. [**Nodes**](/autonomys-network/nodes) 6. [**Subspace Protocol (PoAS Consensus)**](/autonomys-network/consensus) 1. [Genesis](/autonomys-network/consensus/genesis) 2. [Data Flow](/autonomys-network/consensus/data-flow) 3. [Proof-of-Archival-Storage (PoAS)](/autonomys-network/consensus/proof-of-archival-storage) 4. [Proof-of-Time (PoT)](/autonomys-network/consensus/proof-of-time) 5. [Security](/autonomys-network/consensus/security) 7. [**Distributed Storage Network (DSN)**](/autonomys-network/distributed-storage-network) 8. [**Decoupled Execution (DecEx)**](/autonomys-network/decoupled-execution) 1. [Domains](/autonomys-network/decoupled-execution/domains) 2. [Staking](/autonomys-network/decoupled-execution/staking) 9. [**Networking Protocols**](/autonomys-network/networking-protocols) 10. [**$AI3 Rewards & Fees**](/autonomys-network/rewards-and-fees) 11. [**Scalability**](/autonomys-network/scalability) ## Learn more *** * [Subspace: A Solution to the Farmer’s Dilemma](https://gateway.autonomys.xyz/file/bafkr6ibscehgtz4l5ee6rb3tnofcceaztqympdw6k5b6efkoe77uswvoqy) (Whitepaper, 2021) * [Subspace Network Reference Implementation](https://github.com/autonomys/subspace) * [Autonomys: Foundation Layer for AI3.0](https://gateway.autonomys.xyz/file/bafkr6ia6q74kzrtdpfl3scb5v5f2vuvsip7ilfo4qkl27ievd7uvnluw2a) (Whitepaper, 2024) * [Autonomys: Foundation Layer for AI3.0](https://gateway.autonomys.xyz/file/bafkr6ibiqakm4js5yqifosrm2kdtxkbncbya2z2na2a34gaubwirqxt6bi) (Litepaper, 2024) [^1]: We use proof-of-capacity as an umbrella term encompassing proof-of space, proof-of-storage, proof-of-replication, proof-of-space-time, proof-of retrievability, and other storage-based protocols. # Terminology Glossary of Autonomys Network key terms ## $AI3 The [Autonomys Network](#autonomys-network)'s native utility token needed to interact with our [AI3.0](#ai3.0) Ecosystem. $AI3—formerly tSSC (Testnet Subspace Credits) / ATC (Auto Coin)—incentivizes the healthy operation of the network via [farmer](#farmer) rewards and [operator](#operator) transaction fees. $AI3 is divisible up to 18 decimal places to allow for microtransactions. ### Shannon The smallest unit of [$AI3](#usdai3), equal to $$10^{-18}$$$AI3 (0.000000000000000001 $AI3). Named after Claude Shannon, a mathematician, electrical engineer, and cryptographer known as the "father of information theory". Shannon's work was central to the rise of digital computing and laid the foundations for the information age. ## [AI3.0](/autonomys-vision/intro-to-ai3) Decentralized, human-centric, agentic artificial intelligence. ## [Autonomys Network](/autonomys-network/architecture) Hyper-scalable decentralized AI (deAI) [infrastructure stack](/autonomys-network/architecture) encompassing high-throughput permanent [distributed storage](#dsn), data availability and access, and [modular execution](#domain)—all the essential components to [build](/auto-suite/auto-sdk) and deploy secure super dApps (AI-powered dApps) and advanced on-chain agents. ## [Auto Suite](/auto-suite/introduction) Autonomys' product suite, including the [Auto SDK](/auto-suite/auto-sdk), [Auto Agents Framework](/auto-suite/auto-agents) and [Auto ID](/auto-suite/auto-id) for developers, and [Space Acres](/auto-suite/spaceacres-cli), [Auto Portal](https://github.com/autonomys/auto-portal), and the [Autonomys CLI](#autonomys-cli) for [farmers](#farmer) and [operators](#operator). ## Blockchain ### History An ordered, [SCALE-encoded](https://docs.substrate.io/reference/scale-codec/) record of [Autonomys Network](#autonomys-network) blockchain blocks. ### State The current live status of all data stored on the [Autonomys Network](#autonomys-network) blockchain (including wallet balances, smart contract code, etc.); the result of [operators](#operator) executing transactions. ## Client A user interacting with the [Autonomys Network](#autonomys-network) through a light client such as [Substrate Connect](https://docs.substrate.io/learn/light-clients-in-substrate-connect/) or another front-end application. Clients can submit transactions and query the [state](#state), but don't run a [node](#node). ## [Consensus Chain](/autonomys-network/consensus) The [Autonomys Network](#autonomys-network)'s [Subspace](#subspace-protocol) ([PoAS](#poas)) blockchain for consensus between [farmers](#farmer). Consensus is decoupled from more computationally-intensive transaction [execution](#decex), meaning [farming](#farming) is lightweight and accessible, and the [consensus chain](/autonomys-network/consensus) is quick-to-sync. ## [DecEx](/autonomys-network/decoupled-execution) Decoupled execution separates [consensus](/autonomys-network/consensus) (handled by [farmers](#farmer)) from computation (handled by [operators](#operator))⁠, allowing for independent scaling of transaction throughput and storage. DecEx is implemented through [domains](#domain). ## [Domains](/autonomys-network/decoupled-execution/domains) Modular [DecEx](#decex) environments or [appchains](#appchain) with shared security and data availability via [Autonomys](#autonomys-network)' [consensus](#consensus-chain) layer and [DSN](#dsn). Domains support any form of computation or state transition framework, including EVM and WASM. Each domain has its own configurable runtime and gossip network (domain subnet). [Operators](#operator) are incentivized to maintain domains with transaction/execution fees. Domains are conceptually similar to Ethereum rollups, but are integrated into the core [Autonomys Network](#autonomys-network) protocol for horizontal scalability⁠⁠​⁠. ### Appchain An application-specific blockchain leveraging the [Autonomys Network](#autonomys-network) for consensus and storage. Appchains, or [domain](#domains) chains, are customized to the needs of a specific application or use-case. ### Epoch A block interval between each [stake](#staking) allocation readjustment on a [domain chain](#appchain). [Operator](#operator) stakes are fixed for the duration of the domain epoch at its start. The stake distribution is adjusted at the end of each epoch based on new stake deposits, withdrawal requests, and slashing events. ## [DSN](/autonomys-network/distributed-storage-network) Distributed storage network composed of [farmers](#farmer) that have [plotted](#plotting) [pieces](#piece) of [archived history](#archived-history) and serve them to [clients](#client). The DSN handles data storage, retrieval and replication across the network. ## [Node](/autonomys-network/nodes) A participant in [Autonomys](#autonomys-network)' peer-to-peer (P2P) network. The main node-running roles are [farmer](#farmer), [operator](#operator) and [timekeeper](#timekeeper). [Nodes](/autonomys-network/nodes) connects to other nodes via the P2P networking layer. ### [Farmer](/auto-suite/spaceacres-cli/farmers) A [node](#node)-running role responsible for maintaining the [history](#history) and security of the [Autonomys Network](#autonomys-network) [consensus chain](#consensus-chain) and providing storage to the [DSN](#dsn). Farmers earn [$AI3](#usdai3) by pledging disk space to the network, [plotting](#plotting) [pieces](#piece) of [archived history](#archived-history) to disk, [farming](#farming) the created [plot](#plot) for block and vote rewards by producing blocks for consensus, and joining the DSN as nodes for data retrieval. #### [Autonomys CLI](https://docs.autonomys.xyz/farming/advanced-cli/install) [Command Line Interface application](https://docs.autonomys.xyz/farming/advanced-cli/install/) for running [farmer](#farmer) and [operator](#operator) nodes within a terminal instance. #### Archiving The process of converting the [consensus blockchain](#consensus-chain) [history](#history) into [archived history](#archived-history). #### ***Raw Record*** A fragment of [consensus blockchain](#consensus-chain) [history](#history)—the 'useful data' for [PoAS](#poas) consensus—before being [archived](#archiving). #### ***Record*** A [raw record](#raw-record) that has been prepared for [archiving](#archiving). #### ***Archived History*** The immutable ledger of [archived](#archiving), ordered [consensus chain](#consensus-chain) blocks permanently stored across the [DSN](#dsn) in a redundant, verifiable and retrievable way. #### ***Segment*** A fixed-size section of (potentially partial) [consensus chain](#consensus-chain) [history](#history) blocks. There are two types of segment: #### 1. *Recorded History Segment* A [segment](#segment) of [raw records](#raw-record) in a buffer before [archiving](#archiving). #### 2. *Archived History Segment* A [segment](#segment) of [pieces](#piece) of [archived history](#archived-history) converted from a [recorded history segment](#id-1.-recorded-history-segment) by [archiving](#archiving). #### ***Commitment*** A binding, cryptographic commitment to the value and integrity of a specific piece of data that allows the committer ([nodes](#node)) to conceal the committed value and reveal it later. Others can then verify that the committed value matches the original commitment. The [Autonomys Network](#autonomys-network) uses two types of commitment: * **Record Commitment:** a KZG polynomial commitment to the blockchain data in a [raw record](#raw-record). * **Segment Commitment:** a KZG polynomial commitment to hashes of all record commitments in an [archived history segment](#id-2.-archived-history-segment). #### ***Segment Header*** A compact header in an [archived history segment](#id-2.-archived-history-segment) containing the [segment](#segment) index, segment [commitment](#commitment), a pointer to the previous segment header, and information about the progress of block [archiving](#archiving). #### *Witness* A cryptographic proof of the existence of a specific piece of data within a larger dataset, such as a Merkle tree or polynomial [commitment](#commitment). Witnesses are used in the [Subspace Protocol](#subspace-protocol) to efficiently verify the inclusion of data in a [plot](#plot) or blockchain [history](#history) without requiring access to the entire dataset, enabling [farmers](#farmer) and [operators](#operator) to validate data integrity while minimizing bandwidth and computational overhead. #### (Re)Plotting The process of [farmers](#farmer) creating (and maintaining) [plots](#plot) of [archived history](#archived-history) on their disk, allowing for efficient [PoAS](#poas) consensus and retrievability of archived history. #### ***Piece*** A unit of [archived history](#archived-history) from which [archived history segments](#id-2.-archived-history-segment) are composed. Each piece is composed of a [record](#record), a [commitment](#commitment), and a [witness](#witness). #### ***Sector*** A set of encoded [pieces](#piece) written to disk during [plotting](#re-plotting). A sector contains encoded the [record](#record) data from the pieces, the original piece [commitments](#commitment), [witnesses](#witness), and other metadata about stored pieces. #### ***Plot*** A collection of [sectors](#sector) that can be used for [farming](#farming). #### Farming The process of [farmers](#farmer) participating in [Subspace](#subspace-protocol) consensus by competing to solve a puzzle using their [plots](#plot). Farmers farm a block and earn [$AI3](#usdai3) rewards when they are the first to solve the puzzle and submit a valid proof. #### Reconstruction The process of reconverting [archived history segments](#id-2.-archived-history-segment) to [recorded history segments](#id-1.-recorded-history-segment) for seeding new [nodes](#node). ### [Operator](/auto-suite/spaceacres-cli/operators) A [node](#node)-running role responsible for running computation on [domains](#domains) on the [Autonomys Network](#autonomys-network). [Staked](#staking) operators earn [$AI3](#usdai3) by providing compute to the network, running [state](#state) transitions, maintaining state by bundling transactions, validating state [commitments](#commitment), and deterministically executing transaction bundles on [domain chains](#appchain) in the order defined by the [farmers](#farmer)' [consensus chain](#consensus-chain) in exchange for transaction/compute fees from [clients](#client). #### Leader Operator Selected through an [$AI3](#usdai3) [stake](#staking)-weighted VRF (Verifiable Random Function) election process to produce bundles for a [domain](#domains) in a specific time slot⁠.⁠ #### [Staking](/autonomys-network/decoupled-execution/staking) The process of [nominators](#nominator) pledging [$AI3](#usdai3) towards [operators](#operator) on [domains](#domains) in exchange for rewards, locking it up as collateral to support the operation and security of the [Autonomys Network](#autonomys-network). ### [Timekeeper](/autonomys-network/consensus/proof-of-time) A [node](#node)-running role responsible for running the [Proof-of-Time](/autonomys-network/consensus/proof-of-time) chain and maintaining the randomness beacon for the [Autonomys Network](#autonomys-network) [consensus chain](#consensus-chain). ## [Nominator](/auto-suite/spaceacres-cli/operators) [$AI3](#usdai3) holders that [nominate](/auto-suite/spaceacres-cli/operators) tokens towards [operators](#operator) and earn a share of the fees as [staking](#staking) rewards. ## [PoAS](/autonomys-network/consensus) [Proof-of-Archival-Storage](/autonomys-network/consensus), the [Autonomys Network](#autonomys-network)'s custom proof-of-capacity [consensus](#consensus-chain) mechanism. ## [Subspace (Protocol)](https://autonomys.xyz/solution) The [Autonomys Network](#autonomys-network)'s unique [Proof-of-Archival-Storage (PoAS)](#poas) consensus mechanism. # Architecture The Autonomys Network's AI3.0 infrastructure stack Autonomys is a modular, hyper-scalable, storage-based Layer-1 blockchain network that decouples consensus from execution, dividing the core [PoAS consensus](/autonomys-network/consensus) chain—maintained by [farmers](/auto-suite/spaceacres-cli/farmers)—from a nearly unlimited number of secondary [decoupled execution (DecEx)](/autonomys-network/decoupled-execution) chains ([domains](/autonomys-network/decoupled-execution/domains))—maintained by [operators](/auto-suite/spaceacres-cli/operators). Our extensive [distributed storage network (DSN)](/autonomys-network/distributed-storage-network) is a byproduct of the SSD space provided by our farmers to secure the network. The Autonomys Network is an instance of the [Subspace Protocol](/autonomys-network/consensus) based on Substrate and written in Rust. Our permissionless peer-to-peer network allows anyone with an SSD to join, permitting wide participation and engendering strong decentralization, while PoAS consensus ensures efficient data availability and environmentally friendly maintenance of the blockchain's state and immutable history. The modularity provided by our DecEx domains and DSN architecture enables unparalleled scalability and adaptability for developers building on the application layer. Domains support any state transition framework and execution environment, fostering cross-chain interoperability. Key innovations including [Auto ID](/auto-suite/auto-id) and Auto Score—built on domains—provide a secure, verifiable identity system for both humans and AI entities that helps address the fundamental challenge of establishing trust in an increasingly AI-integrated world, at the same time as allowing for content authentication, and delegation of permissioned authority. Autonomys' AI3.0 infrastructure stack, composed of four layers, forms a comprehensive ecosystem that abstracts away the complexities of blockchain development while enabling unprecedented scalability, security and flexibility for developers building any conceivable on-chain AI application:

Autonomys AI3.0 Stack

* [***dApp/Agent Layer***](/autonomys-vision/use-cases)***:*** facilitating the development and deployment of super dApps (AI-powered dApps) and Autonomys Agents ([Auto ID](/auto-suite/auto-id)-integrated on-chain agents) for verifiable digital interaction. * [***Execution/Domain Layer***](/autonomys-network/decoupled-execution)***:*** secure, scalable distributed compute for AI training, inference and agentic workflows. * [***Consensus Layer***](/autonomys-network/consensus)***:*** verifiable decentralized sequencing and transaction validation for shared security. * [***Storage Layer***](/autonomys-network/distributed-storage-network)***:*** multi-layer distributed storage ensures data integrity and permanent availability—crucial for storing vast amounts of AI data. Utilizing the [Subspace Protocol](/autonomys-network/introduction), with its innovative hybrid [Proof-of-Archival-Storage (PoAS)](/autonomys-network/consensus/proof-of-archival-storage)/[Proof-of-Time (PoT)](/autonomys-network/consensus/proof-of-time)/[Nominated Proof-of-Stake (NPoS)](/autonomys-network/decoupled-execution/staking) consensus mechanism, our decentralized physical infrastructure network (DePIN) incentivizes active participation through the permissionless contribution of any amount of storage space or compute, or staking of any amount of tokens, permitting unprecedented accessibility. ## Autonomys Network Visualization {% embed url="" %}

Autonomys Network visualization

# Advancing Blockchain An overview of how the Autonomys Network advances blockchain technology Autonomys' Subspace Protocol is designed from first principles to resolve several critical challenges associated with blockchain technology. ## Resolving the blockchain trilemma The Autonomys Network resolves the blockchain trilemma—simultaneously achieving [scalability](/autonomys-network/scalability), [security](/autonomys-network/consensus/security) and decentralization—by utilizing accessible SSD-based [PoAS consensus](/autonomys-network/consensus), and independently scaling storage, transaction throughput, and bandwidth. This balanced approach means none of the key properties of a healthy blockchain network are sacrificed.

The blockchain trilemma

## Resolving the farmer's dilemma & increasing accessibility In an effort to make blockchains more energy-efficient, egalitarian and decentralized, several protocols employ [proof-of-capacity (PoC)](/autonomys-network/introduction)-based consensus that replaces compute-intensive mining with storage-intensive farming. PoC consensus introduces a unique mechanism design challenge known as the 'farmer's dilemma', which suggests that existing constructions are not in fact incentive-compatible. In short, farmers must decide whether to allocate scarce storage resources to maintain the chain state and history, or maximize the amount of space they pledge towards consensus. Rational farmers (seeking maximum rewards) will always choose the latter, at best becoming light nodes, while at worst encouraging pooled farming under a few trusted operators.

The farmer's dilemma

To resolve this dilemma, Autonomys farmers maintain only minimal state and history, while retaining the security properties and decentralization benefits of being a full node. Farmers store the blockchain history collectively, many times over, with each farmer storing as many replicas as their disk space allows. Autonomys Network consensus is based on [Proof-of-Archival-Storage (PoAS)](/autonomys-network/consensus)—farmers' proofs of their replicated storage of the blockchain history. The [Subspace Protocol](/autonomys-network/consensus) decouples consensus and execution/computation, meaning farmers only propose the ordering of transactions, while staked operators maintain the state and compute transitions. This node role separation significantly reduces the storage and compute requirements for running a farmer node—even in an Ethereum-style execution model—allowing for higher levels of participation.

How Autonomys resolves the farmer's dilemma

## Eliminating blockchain bloat The [Subspace Protocol](/autonomys-network/consensus) is designed to overcome the critical issue of blockchain bloat—the tendency of blockchains to become more centralized over time, especially as they scale. Bloat is the result of every full node storing the chain's entire transaction history and resulting execution state. Autonomys eliminates bloat by uniquely combining the best parts of Layer-1 blockchains including Ethereum, Filecoin and Chia into a new network with a novel storage-based PoAS consensus protocol, permanent distributed storage infrastructure, and scalable decoupled execution framework. ## Addressing state bloat To resolve the problem of state bloat, Autonomys introduces a [decoupled execution (DecEx) framework](/autonomys-network/decoupled-execution). DecEx separates the probabilistic process of coming to consensus over ordering transactions from the deterministic process of executing them. Farmer nodes confirm the availability of transactions and provide an ordering, while a secondary network of staked operator nodes executes the transactions and maintains the resulting chain state. Decoupling these roles permits different hardware requirements for each node type, allowing farming to remain lightweight and open to anyone, while also providing a foundation for scaling execution both vertically—based on the hardware capabilities of operators—and horizontally—by later partitioning operators into different namespaced execution domains. ## Scaling blockspace Blockspace is space on a blockchain that can run code or store data. The overall execution throughput of a blockchain is ultimately constrained by the blockspace bandwidth. To achieve optimal throughput, our [scalability](/autonomys-network/scalability) framework seeks to increase the blockspace linearly as more nodes contribute resources to the network—without reducing security or decentralization. The Autonomys Network achieves optimal scalability through Orthogonal Execution (OE) by first horizontally scaling the blockspace of the base data availability layer and then vertically scaling the transaction throughput for each domain. OE starts with the unique properties of the Subspace Protocol and extends them with several ideas originating within the Tse Lab at Stanford University. These include the Prism protocol for vertical scaling and the Semi-AVID-PR scheme for distributed data availability. ## Aligning incentives for optimal scalability In order to economically secure the network in an open environment, Autonomys uses a novel algorithm that dynamically adjusts the cost of blockspace in response to changes in supply and demand, naturally keeping the network [incentive-compatible](/autonomys-network/rewards-and-fees) for both farmers (providing storage and data availability bandwidth) and operators (providing raw compute power). The Autonomys Network represents the world's first two-sided marketplace for blockspace, enabling a dynamic on-chain cost-of-blockspace and a stable off-chain price-of-blockspace without relying on centralized control or coordination. On one side are farmers, who collectively supply blockspace bandwidth through their storage of the blockchain history, and on the other side are dApp developers and users, who demand blockspace to deploy, run and use applications. Autonomys' marketplace algorithm automatically adjusts the on-chain cost-of-blockspace paid out to farmers based on real-time supply and demand. When demand is high, the cost rises to incentivize more farmers to join. When demand is low, the cost falls to disincentivize over-investment in storage. This dynamic adjustment process occurs transparently on-chain through the protocol rules. By combining this approach with existing scalability frameworks, Autonomys can achieve linear scaling of the blockspace as more nodes join the network, without sacrificing security or decentralization. ## Conclusion: From Web3 to AI3.0 The Autonomys Network represents a dual solution to both the: • challenges of security, decentralization, verifiability and scalability facing web3 infrastructure—embodied in the farmer’s and verifier’s dilemmas, and the blockchain trilemma. • risks and opportunities posed by the emerging AI-augmented world. In implementing our cutting-edge blockchain technologies, we have not only built a robust, decentralized system that addresses the immediate challenges of permanent storage, provenance and compensation for AI training data, but through our verifiable AI3.0 infrastructure and Auto ID, also laid the groundwork for a future where humans and Autonomys Agents can interact in a transparent, secure, and trustworthy manner. # Nodes Autonomys Network node roles and types ## Node roles ### Farmer **Farmers** secure the [PoAS consensus](/autonomys-network/consensus) chain by pledging disk space to the network. They are incentivized to store data through [$AI3](/autonomys-network/rewards-and-fees) block rewards and fees. A farmer plots pieces of archival history to disk, farms the created plot for block rewards, and joins the [DSN](/autonomys-network/distributed-storage-network) as a data retrieval node (for syncing nodes and returning data to clients). As they do not have to store the blockchain history alongside their plot, farmers can dedicate all their available space to farming. Farmers [require](https://www.autonomys.xyz/space-acres) only an SSD drive and an off-the-shelf CPU to participate, making Autonomys one of the most accessible blockchain networks, and allowing it to become the most decentralized. ### Operator **Operators** maintain the state of [DecEx](/autonomys-network/decoupled-execution) chains and run computations on [domains](/autonomys-network/decoupled-execution/domains). They are incentivized to execute transactions and manage state transitions through [$AI3](/autonomys-network/rewards-and-fees) transaction fees. ### Timekeeper **Timekeepers** run the [Proof-of-Time](/autonomys-network/consensus/proof-of-time) chain and maintain the randomness beacon for the [consensus](/autonomys-network/consensus) chain. They are responsible for evaluating the delay function (within the target time slot duration of 1 second) and announcing the outputs to other nodes, requiring a powerful last-generation CPU. The [Subspace Foundation](https://subspace.foundation) maintains several timekeepers as a public good. ## Node types ### Full nodes **Full nodes** process all blocks and serve peers, preserving the blockchain's state and *recent* history for a configurable number of recent blocks until it is archived and pruned. Full nodes support newly joined nodes by providing them with the necessary block data to start their participation. Running a full node allows the participant to verify all blocks, ensuring independent auditability. All farmers, operators and timekeepers are full nodes by default. Autonomys promotes network decentralization by keeping the hardware requirements for running full nodes low enough for an individual to set up and run one at home. The health, robustness and censorship-resistance of the Autonomys Network lies in the continuous online presence of numerous independently managed full nodes spread [across all continents of the world](https://telemetry.subspace.network). ### Archival nodes **Archival nodes** process all blocks and serve peers, preserving the blockchain's state and *entire* history. Archival nodes are useful for faster historical block retrieval and block explorers. All farmers, operators and timekeepers can become archival nodes. The [Subspace Foundation](https://subspace.foundation) maintains several archival nodes as a public good, but they are not necessary for the long-term functioning of the chain. ### Light nodes (clients) **Light nodes (clients)** connect to full nodes and process block headers, but do not preserve the blockchain's state or history. Light nodes are useful for low-resource devices used by clients (users interacting with the network) and can be run in a browser with [Substrate Connect](https://github.com/paritytech/substrate-connect). # Subspace Protocol (PoAS Consensus) Autonomys's Proof-of-Archival-Storage (PoAS)-based consensus layer The Autonomys Network is an instance of the Subspace Protocol—a unique, lightweight, [secure](/autonomys-network/consensus/security) Proof-of-Archival-Storage (PoAS) consensus and data availability mechanism. The Subspace Protocol ensures there is a single source of truth for the blockchain's state and history across all nodes participating in the network. Based on storing pieces of the chain history in allocated disk space, rather than compute power or staked assets, PoAS consensus is eco-friendly, permissionless and fair, remaining accessible to anyone with an SSD—a widely distributed commodity. To participate in a Proof-of-Archival-Storage, [farmers](/auto-suite/spaceacres-cli/farmers) first create and store as many provably unique partial replicas of the chain history as their allocated disk space allows, before responding to random, publicly verifiable storage audits, which allow them to forge new blocks. This stands in contrast to the Proof-of-Capacity (PoC) protocols proposed by [Spacemint](https://ia.cr/2015/528), [Chia](https://chia.net/wp-content/uploads/2022/07/ChiaGreenPaper.pdf), and [SpaceMesh](https://eprint.iacr.org/2016/035.pdf), in which nodes store randomly generated data, rather than useful files. In incentivizing the storage of the blockchain's history, PoAS also resolves the key mechanism design failure that has hindered the scalability of PoC chains like Filecoin and Chia and led to their centralization. PoAS—inspired by Sergio Lerner’s [Proof-of-Unique-Blockchain-Storage](https://bitslog.com/2014/11/03/proof-of-local-blockchain-storage/) mechanism (but utilized directly for consensus)—combines the high security of Bitcoin-style Proof-of-Work (PoW) with the energy-efficiency of Ethereum-style Proof-of-Stake (PoS). The Subspace Protocol was built to provide a superior user experience (UX) to existing PoC protocols, while maintaining the highest level of consensus security. Its most relevant UX and performance metrics are: * *Setup time:* hours–days (depending on allocated disk space) * *Proof-generation time:* < 1 second * *Proof size:* < 1 KB * *Verification time:* 0.001–0.01 seconds The latest iteration of the [Subspace Protocol](https://github.com/subspace/consensus-v2-research-paper/blob/main/consensus) uniquely combines [KZG polynomial commitment](https://cacr.uwaterloo.ca/techreports/2010/cacr2010-10.pdf), [erasure coding](https://iqua.ece.toronto.edu/papers/junli-survey13.pdf), and [function inverting](https://ia.cr/2017/893) to address outstanding design challenges, significantly improving upon [previous versions of the protocol](https://cdn.prod.website-files.com/61526a2af87a54e565b0ae92/617759c00edd0e3bd279aa29). Read the [Dilithium research paper](http://github.com/subspace/consensus-v2-research-paper/blob/main/consensus_v2.pdf) for a more detailed description of our revised consensus design, and our [original Subspace whitepaper](https://gateway.autonomys.xyz/file/bafkr6ibscehgtz4l5ee6rb3tnofcceaztqympdw6k5b6efkoe77uswvoqy) for a full explanation of its fundamental ideas. ## Contents Read the following subsections for technical details of the Subspace Protocol consensus mechanism: 1. [**Genesis**](/autonomys-network/consensus/genesis) 2. [**Data Flow**](/autonomys-network/consensus/data-flow) 3. [**Proof-of-Archival-Storage (PoAS)**](/autonomys-network/consensus/proof-of-archival-storage) 1. [**Archiving**](/autonomys-network/consensus/proof-of-archival-storage/archiving) 2. [**Plotting**](/autonomys-network/consensus/proof-of-archival-storage/plotting) 3. [**Farming**](/autonomys-network/consensus/proof-of-archival-storage/farming) 4. [**Proof-of-Time (PoT)**](/autonomys-network/consensus/proof-of-time) 5. [**Security**](/autonomys-network/consensus/security) ## Technical Overview PoAS is a three-phase protocol, consisting of: * [**Archiving**](/autonomys-network/consensus/proof-of-archival-storage/archiving)**:** a recurring deterministic phase completed by all farmer nodes as the blockchain expands. * [**Plotting**](/autonomys-network/consensus/proof-of-archival-storage/plotting)**:** a unique setup phase completed individually by each farmer node. * [**Farming**](/autonomys-network/consensus/proof-of-archival-storage/farming)**:** a probabilistic audit phase based on a recurring slot challenge from a secure randomness beacon with a frequency of one challenge per second.
A key design challenge is how to ensure the uniqueness of each farmers' plot. As the blockchain's history is not unique to any one farmer, farmers cannot simply store the raw chain history, otherwise dishonest farmers could share a single copy of the chain history to emulate an unlimited amount of disk space. PoAS solves this as follows: ### [Archiving](#archiving) Before plotting, farmers must prepare the raw blockchain history for compatibility with the Subspace plotting protocol by archiving. Archiving applies error-correction coding—specifically the Reed-Solomon code—to guarantee that even if a piece of data (a collection of blocks) is not stored by any farmer, it can be recovered by other pieces. The replication factor used is 1/2, meaning half the network's storage is dedicated specifically to implementing this error-correction technique. This is much more efficient for recovery purposes than using this space to store each block twice. Archiving also utilizes KZG polynomial commitment—a type of cryptographic commitment scheme—to facilitate the later farming phase, during which farmers prove that they stored a certain piece of chain history. ### [Plotting](/autonomys-network/consensus/proof-of-archival-storage/plotting) During plotting, farmers create their own unique plots in two steps: 1. A deterministic algorithm (involving the farmer's ID, the current blockchain height, and other factors) picks pieces of the blockchain history for the farmer to store on their disk. This ensures—with high probability—that pieces are allocated uniformly at random, and therefore that no piece of history will be missing. 2. A deterministic algorithm (involving the farmer ID and piece of history) 'masks' the farmer's assigned pieces with unique, verifiable 'masking data'. Masking involves producing a string of bits that are XOR-ed with the bit representation of the selected piece of history. This ensures different farmers obtain different masking data for the same piece and each plot contains unique pieces of data, meaning dishonest farmers cannot share the same raw history. Autonomys adopts Chia's cryptographic protocol as it demands both time and electricity for generation, preventing dishonest farmers from attempting to produce the masking data on the fly and re-using their raw data for several plots. ### [Farming](/autonomys-network/consensus/proof-of-archival-storage/farming) Once a farmer has created their plot, they can start farming it. Farming is similar to mining in other blockchains, where block challenges are drawn and miners (farmers) attempt to produce a block with their resources (stored pieces of chain history). Block challenges are drawn from a secure randomness beacon which updates every second. The randomness is obtained from an AES-based [Proof-of-Time (PoT)](/autonomys-network/consensus/proof-of-time) component anchored to the blockchain history itself. In order to win a block challenge and produce a block, a farmer must submit a proof including both the raw piece of chain history and its masking data. As the masking data is verifiable, anyone can check that it was the unique masking data for that specific piece of history and farmer ID. # Genesis The creation of the Autonomys Network consensus chain The genesis process of Autonomys' consensus chain (launched on mainnet in November 2024) involved initializing and configuring the blockchain's starting state to ensure its functionality, following these steps: 1. **Genesis Configuration**: Creating a genesis configuration defines the blockchain's initial parameters, including the consensus parameters, initial balances, boot nodes, and network protocol settings. 2. **Genesis Block Creation**: After the configuration is complete and the initial state is defined, the genesis block is created. Randomly generated data the size of one segment (128MiB) is attached to the serialized encoding of the genesis block to bootstrap step 4. 3. **Proof-of-Time Initialization**: [Timekeepers](/autonomys-network/nodes) initialize the randomness beacon via the [Proof-of-Time (PoT)](/autonomys-network/consensus/proof-of-time) chain, which serves as a global 'clock' for the network where the current 'time' is the height of the PoT chain. It also provides the source of randomness for block production. 4. **First Segment Archiving**: The data attached to the genesis block triggers the [archiving](/autonomys-network/consensus/proof-of-archival-storage/archiving) of the first segment of the canonical history of the chain. It produces the first 256 pieces and announces them to the [DSN](/autonomys-network/distributed-storage-network). 5. **History Seeding**: The Autonomys Labs team uploads an initial archive of useful seed data, including the whitepaper, archived data from previous testnets, and community-nominated submissions, to the network. 6. **Initial Plotting**: [Farmers](/autonomys-network/nodes) create their plots from the newly archived pieces. As soon as [plotting](/autonomys-network/consensus/proof-of-archival-storage/plotting) is complete, they can start [farming](/autonomys-network/consensus/proof-of-archival-storage/farming) blocks. 7. **Block Production**: Although block production begins, [$AI3 farming rewards](/autonomys-network/rewards-and-fees) are not issued until the Space Race is complete. Meanwhile, full nodes start syncing the chain and participating in consensus. 8. **Space Race**: The [Space Race](https://www.autonomys.xyz/post/announcing-the-autonomys-mainnet-launch-space-race) is a collaborative effort between farmers to reach a set goal of pledged space that will automatically enable block and vote rewards. It ensures a safe cold start for the network during which we can bootstrap its [security](/autonomys-network/consensus/security). 9. **$AI3 Rewards Enabled**: After the Space Race's conclusion, block and vote rewards are issued to farmers who successfully audit their plots for a block or vote-eligible solution. Rewards decrease over time according to our [dynamic token issuance schedule](https://www.autonomys.xyz/post/from-space-race-to-long-tail-crafting-a-sustainable-token-issuance-model-for-a-resilient-autonomys-network). # Data Flow The flow of data through the Autonomys Network From the moment a transaction is submitted to the Autonomys Network to the point it is permanently archived, data goes through several stages: 1. A transaction is validated and included in a consensus chain block directly or through the inclusion of [domain](/autonomys-network/decoupled-execution/domains) bundles. 2. The transactions and bundles in the block are executed, activating a global domain state change. 3. Once the block reaches a certain depth (currently 100 blocks), it is [archived](/autonomys-network/consensus/proof-of-archival-storage/archiving) alongside other blocks, becoming part of the chain's archival history. 4. Newly archived pieces are added to [farmers](/autonomys-network/nodes)' caches through the [distributed storage network (DSN)](/autonomys-network/distributed-storage-network) and replicated multiple times throughout the network. 5. Pieces are encoded into farmer [plots](/autonomys-network/consensus/proof-of-archival-storage/plotting) on disk for permanent storage. 6. When a client requests the archived transaction data, the original data is reconstructed from archived pieces on the fly.

Blockchain Data Flow

## Blocks ### Block structure and limits A PoAS consensus chain block follows the general structure of a standard blockchain block—it consists of a body and a header, and points to a parent block. Consensus chain block headers contain metadata about the block that allows for the verification of the chain's [security](/autonomys-network/consensus/security), while the body contains transactions and domain bundles. Transactions include transfers, votes and fraud proofs. Domain bundles are sets of transactions from a particular domain (e.g., [Auto EVM](/autonomys-network/decoupled-execution/domains/auto-evm) contract calls). Each block has a certain length and weight. Length is the amount of storage a block consumes on the network—equal to the size of the encoded transactions and bundles in the block body in bytes. Weight is the estimated time it would take to execute a block—equal to the sum of the compute weights of all the transactions in the body. Currently, consensus chain blocks are limited to 3.75 MiB of length and 1.5 seconds of compute weight for normal user transactions (with up to 1.25 MiB and 0.5 seconds extra for system extrinsics like votes or chain updates). ### Consensus chain block headers Consensus chain block headers contain the: * Block number in the chain of blocks * Hash of the parent block * Merkle root of the trie of extrinsics included in this block * Merkle root of the state trie after processing this block * Time slot number claimed by the block producer * Global randomness at the claimed time slot (derived from the [proof-of-time (PoT)](/autonomys-network/consensus/proof-of-time) chain) * Solution to the slot challenge for the claimed time slot (includes a winning chunk of history, a proof-of-space for the farmer's plot, and a KZG witness that the winning chunk is part of the archival history at the claimed height) * Solution range used to find the winning chunk of history * Signature of the farmer over the header ### Domain bundles A bundle contains multiple transactions from a particular domain (e.g., Auto EVM contract calls) deterministically ordered for efficient execution, propagation and inclusion in blocks. Bundles contain a signed header and a list of transactions. A bundle header contains the: * Domain ID (e.g., Auto EVM) * Operator ID of the bundle producer * Merkle root of the trie of transactions included in this bundle * Execution receipt that should extend the domain receipt chain * Size of the bundle body in bytes (to calculate the storage cost) * Total estimated weight of all extrinsics in the bundle (to prevent overloading the bundle with compute) * Time slot claimed by the bundle * Global randomness at the claimed time slot (derived from the PoT chain) * Proof-of-election of the operator as bundle producer for the claimed time slot (based on the slot challenge and the operator's stake in the current epoch) Each domain bundle can be visualized as 'a block inside a block', with its bundle header containing information about the domain and the bundle producer. Any consensus chain block may contain many bundles from different domains without burdening the consensus layer, as farmers check if bundles are well-formed and package them within a block, but do not execute any of the computations inside them. ### Domain blocks Domains are application-specific blockchains (app-chains) with separate namespaced execution environments that rely on the consensus chain for shared security, data availability, settlement, and interoperability. Domain chains consist of domain blocks that only contain bundles relevant to their domain.
# Proof-of-Archival-Storage (PoAS) An overview of the cryptographic primitives used by the Subspace Protocol ## Hashing Hashing provides succinct commitments to arbitrary data (blocks, transactions, etc.) that are deterministic, verifiable and cannot feasibly be reversed. The Subspace Protocol uses the BLAKE2b-256 and BLAKE3 hash functions in different places. ## Digital signatures Digital signature schemes secure different parts of consensus by providing a means of authentication. We currently use Schnorr/Ristretto x25519 (also known as sr25519) as the key derivation and signing algorithm (part of the [schnorrkel](https://github.com/w3f/schnorrkel) library): * Non-canonical Schnorr signatures are used to sign rewards for a newly forged block (as defined in Substrate) and votes by farmers, as well as transactions and transaction bundles by domain operators. * Canonical (deterministic) signatures are used as a verifiable random function (VRF) in the slot leader election among domain operators. A canonical scheme is necessary for these cases to prevent attackers from repeatedly signing until they produce an election solution that meets the threshold (as part of a grinding attack). ## Erasure coding An erasure code extends any given data such that the full original data can be recovered from a subset and is protected against loss. The Subspace Protocol uses erasure coding to encode and decode blockchain history pieces and their KZG commitments in an archived segment, allowing for the distributed storage of pieces across farmers, and protecting the data against loss in the event of any failures or network partitions. Erasure code is also used in plotting—together with proofs-of-space—to create unique, easily recoverable plot files for each farmer. We currently use a Discrete Fourier Transform-based systematic Reed-Solomon code with a rate of 1/2 over the field 𝐹𝑟, where 𝑟 is the [size of the subgroup of points](https://hackmd.io/@benjaminion/bls12-381#Curve-equation-and-parameters) on the BLS12-381 curve for the piece chunks, and the same approach over the subgroup of elliptic curve points $$G\_1$$ for piece commitments. ## Kate-Zaverucha-Goldberg (KZG) polynomial commitments KZG polynomial commitment schemes allow for *constant*-sized inclusion proofs for arbitrary-sized data sets, specifically: * The commitment size is *constant* and equal to one elliptic curve point of an elliptic curve group that admits pairings. * The witness size is *constant* and equal to one curve point. * Verification time is *constant* and requires two point-scalar multiplications and two pairings regardless of the size of the committed data set. * Proving time (commitment and witness generation) is *linear* in the size of committed data. The Subspace Protocol uses BLS12-381, which has 48 bytes for elliptic curve points (commitments and witnesses) serialized in compressed form. The protocol uses the KZG commitment scheme to commit to the archived pieces of history and segments of pieces so farmers storing pieces in their plots can always succinctly prove that a particular piece is a valid part of the blockchain history, and clients who request pieces can verify the proofs efficiently. The synergy between KZG and Reed-Solomon erasure code allows us to have: * succinct commitments to data of arbitrary size * succinct witness of the inclusion of data fragments in the blockchain history * efficient verification * provably correct erasure coding KZG requires a one-time trusted setup of the universal reference values (public parameters). In the spirit of interoperability, the Subspace Protocol uses the same reference values as Ethereum, as computed during a distributed multi-party computation ceremony held by the Ethereum Foundation. This permits cross-chain compatibility of KZG proofs between Autonomys and Ethereum. ## Merkle trees Merkle trees provide succinct commitments (Merkle roots) to arbitrary-sized data sets with efficient *logarithmic*-sized inclusion proofs. The Subspace Protocol uses Merkle trees for: * extrinsics sets in blocks (as defined in the Substrate framework) * the state of the blockchain (as defined in the Substrate framework) * execution traces for domain blocks ## Encoding mapping Encoding provides a means to make useful data (i.e. chunks of blockchain history) look like random data, while allowing for the retrieval of the useful data through decoding. The Subspace Protocol uses simple XOR as an encoding function. # Archiving The first phase of the Subspace Protocol **Archiving** transforms the chain blocks at a configured depth (currently 100 blocks) from the end of the chain into a canonical history ready to be distributed to farmers for storage. Our archiving construction is primarily based on the paper '[*Information Dispersal with Provable Retrievability for Rollups*](https://eprint.iacr.org/2021/1544)**'** from the Tse Lab at Stanford University. The key ideas we inherit from this paper are viewing the data to be archived as a matrix, and taking a “1.5D approach” with column-wise erasure coding and row-wise KZG commitment. Combining the polynomial nature of the Reed-Solomon erasure code and KZG with the homomorphic properties of KZG guarantees the consistency, retrievability, and efficient verifiability of the archived data. ## Background When a block reaches archiving depth, its contents are added to a raw chain history buffer. The buffer is then sliced into *records*. * A *record* of blockchain history is a vector of $$2^{15}$$ chunks. * A *chunk* is the smallest unit of data measurement (254 bits, rounded to 32 bytes by padding with 0 for convenience) and a field element for KZG. * A *piece* is a record concatenated with a KZG commitment and a witness of inclusion in a specific segment. The archiving process produces segments of pieces.

Archived piece

## Workflow The blockchain history data is archived when it reaches the archiving depth to avoid forks and reorganizations. The Subspace Protocol begins archives 128MiB segments of raw blockchain history when there are enough blocks at the current archiving depth to fill a segment, as follows: 1. Slice the recorded history segment into 128 source records and stack them into a matrix (so each row is a record). 2. Commit to chunks of each source record (each row) under the KZG vector commitment scheme. 3. Erasure code each column by interpolating a polynomial over the source record chunks in that column and evaluating the polynomial on twice as many points. As a result, the matrix now has twice as many rows—256—and consists of 128 source and 128 extended (parity) records. 4. Erasure code the source record commitments similarly by interpolating a polynomial over the source record commitments in that column and evaluating the polynomial on twice as many points. This allows us to show that the erasure coding of data was performed correctly with the homomorphic property of Reed-Solomon erasure code and KZG. As a result, the extended commitments (yellow boxes in the diagram) obtained by erasure coding the source commitments are the same as if we were to commit to the extended rows.

Archived segment

5. To tie the 256 records and 256 commitments to those records together into a segment, commit to the record commitments, and obtain the segment commitment. 6. Compute a witness for each record commitment inclusion in the segment commitment. With this two-tier commitment, we can later show that a given chunk belongs to a specific record and that record belongs to an archived segment and, thus, to the canonical history of the chain. 7. Build 256 pieces, where each piece consists of a 1MiB record, a 48-byte commitment to record data, and a 48-byte witness of inclusion in a segment. 8. Append the new pieces to the canonical history and store the segment commitment in the chain state. The segment commitment is also included in the successive segment to link back to the last segment and form the chain of segments that represent the canonical history of the blockchain. Once a segment has been archived and the pieces are ready for the farmers to store, the next phase is [plotting](/autonomys-network/consensus/proof-of-archival-storage/plotting). # Plotting The second phase of the Subspace Protocol **Plotting** is the process of creating and maintaining plots on a disk, during which pieces are gathered and organized into plots of several sectors. Each sector contains an encoded replica of a uniformly random sample of pieces across all archived history. This sampling ensures that the data is distributed among farmers proportionally to their pledged disk space and replicated evenly. Plotting is based on two core ideas: * Erasure coding helps protect the data against loss in the event of failures and network partitions. * Memory-bandwidth-bound encoding provides a more cost-effective and eco-friendly alternative to proofs-of-work, while providing provable time/memory trade-offs and security guarantees. Combining these two ideas allows us to create unique, provable replicas for each farmer that are difficult to fake with computation or to compress. This scheme also makes scanning and verifying the plots easier, ensuring the chain history data is recoverable. Our memory-bandwidth-bound encoding construction is inspired by the [Chia](https://www.chia.net/) protocol paper '[*Beyond Hellman's Time-Memory Trade-Offs with Applications to Proofs of Space*](https://www.semanticscholar.org/paper/Beyond-Hellman's-Time-Memory-Trade-Offs-with-to-of-Abusalah-Alwen/39e70d67eeb5ce140171f6d0629daec3b54d74f3)**'**. The Subspace Protocol adopts a custom implementation of the Chia Proof-of-Space (PoS) plotting function as a memory-bandwidth-bound function to encode, or 'mask', the pieces in farmer plots. ## Background In short, the PoS plotter generates a table of permuted outputs from a set of random functions. The table size is determined by a memory bandwidth requirement parameter *k* set to 20, and the random functions are determined by a *seed*. When challenged at an *index*, the table outputs a short *proof-of-space* that can be efficiently verified. We do not use the proof-of-space directly to verify that a farmer has pledged a certain amount of space, as Chia does. Instead, we use it to prove that a farmer utilized the required memory bandwidth for encoding the plot.

PoS Table

## Workflow A plot can cover an entire disk or span across multiple disks, and there is no limit to the amount of storage a farmer can pledge to the network. Plots consist of equally-sized sectors (around 1 GiB each). Each sector is a pseudorandom selection of 1,000 pieces, uniformly sampled throughout the history up to that point. For example, if the farmer creates a new sector when the history consists of 50,000 pieces (50 GiB), the 1,000 pieces for this sector will be a uniform selection from the existing 50,000 pieces. In addition, the farmer must save the current history size, as it will determine when the sector will need to be updated with newer pieces.
Once a farmer has obtained all 1,000 pieces for a sector from the network, they create an encoded replica. Only the piece’s historical data (the record) is encoded. The KZG commitment and witness included in a piece are saved separately in the sector metadata as they will be needed later for farming. For each record, the plotting algorithm performs the following steps in memory: 1. Erasure code (extend) the record data by interpolating a polynomial over chunks of the record. 2. Derive a unique pseudorandom and verifiable *seed*. 3. Based on this *seed*, generate a proof-of-space table using memory bandwidth resources set by the global protocol memory requirement parameter *k*. This memory-intensive computation prevents malicious farmers from creating replicas after the new block challenge is announced, making it more rational for them to store the replica rather than try to compute it on the fly every time. 4. Query the generated table for enough ($$2^{15}$$) proof-of-space values to mask every chunk of the record.
5. Encode each extended record chunk by XOR-masking it with the corresponding proof-of-space value.
After all records in the sector have been encoded as described, the farmer spreads them into s-buckets chunk-wise. Ultimately, each bucket will contain chunks from all records. The first bucket will have the first chunks of each record; the second bucket will have the second chunks, and so on. The s-buckets are then written to disk, and the plotting process of the sector is complete in a single write operation.
Each bucket represents a potential winning ticket in the block proposer lottery. For each challenge, a farmer will scan one s-bucket (containing one chunk of each record they store in a sector) to check whether any of them are eligible to win a block. As a result, a farmer has a unique encoded replica that is difficult to compress or compute on demand. An economically rational farmer is incentivized to store as many honestly encoded replicas as possible to maximize their chances of winning a block. ## Replotting As the chain grows, we need to ensure that new data is replicated as much as older data in the blockchain history. To keep this replication factor constant, farmers must periodically update their plots by replotting expired sectors with a new selection of pieces. The expiry point for a sector is determined by the history size at the time the farmer initially plotted the sector, and is randomly assigned to occur sometime before the history size quadruples (i.e., if a farmer plotted a sector when the history size was 50 GiB, the expiry point will occur before the history reaches 200 GiB). When a sector reaches its expiry point, the block proposer challenge solutions coming from this sector will no longer be accepted by other peers, incentivizing the farmer to update their plot. When replotting, farmers erase the expired sector and repeat the plotting process anew, replicating a fresh history sample. Each replotting creates a new sector in memory and saves it to disk in a single write operation.
In a plot spanning multiple GBs, sectors will be updated randomly, one at a time, so replotting is amortized over a long period, meaning a farmer never needs to erase and re-create their whole plot and miss out on challenges. The plot refreshing will be practically invisible to the farmer and allow their uninterrupted participation in consensus. The bigger the chain grows, and the longer the farmer participates in the network, the less frequent the replotting on their disks will be. After [genesis](/autonomys-network/consensus/genesis), the network was seeded with 20 GiB of history, meaning farmers who joined after the seeding started plotting with an initial history size of 160 segments. Assuming a 1 TB SSD plot, a farmer would thus need to replot 3.5 TB of data on average by the time the chain history reaches 1TB in size, 6.2 TB of data by the time history reaches 10 TiB, and 8 TB by the time history reaches 50 TiB. Given the common TBW (Total Bytes Written) for consumer grade 1 TB SSDs of 300-600 TB, Autonomys farming requires under 3% of the SSD's total endurance to farm over several years (for comparison, Ethereum's full chain data size is \~21 TiB as of February 2025 via [Etherscan](https://etherscan.io/chartsync/chainarchive)).

Average TB replotted on a 1 TB SSD from genesis to 10 TiB (40,960 archived segments)—the increase in the amount of data replotted slows as the chain grows

The next and final phase of Subspace Protocol consensus is [farming](/autonomys-network/consensus/proof-of-archival-storage/farming). # Farming The third phase of the Subspace Protocol **Farming** involves solving block challenges based on previously created plots in order to participate in consensus. Plot audits are designed to be SSD-friendly, favoring a random read approach over large sequential reads, and optimized for typical SSD read size. For illustration, a farmer only needs to read below 32KiB at a random location per sector to check for a solution, and they only need to read more if their solution is eligible to win the block. ## Background The difficulty of farming is defined by the solution range: the narrower the solution range, the fewer possible chunks exist within that range, the smaller the probability for any given farmer to be storing such chunks on their disks. Similarly to Bitcoin, the Subspace Protocol uses an automatic difficulty adjustment mechanism to address fluctuations in network storage and keep block times relatively stable. The Autonomys Network currently targets a block time of approximately 6 seconds. The difficulty is adjusted every 2016 blocks based on the actual time it took to farm the previous 2016 blocks.

Farming

## Workflow After a farmer has [plotted](/autonomys-network/consensus/proof-of-archival-storage/plotting) at least one sector, they can begin farming. As soon as they observe a new challenge from the global randomness beacon, farmers scan each plot sector for a solution and propose a block if they find one, as follows: 1. For each sector, derive a corresponding audit index. 2. Read from disk the s-bucket at that index. 3. Scan it for a chunk within the acceptable solution range from the block challenge. As each bucket contains chunks from all records, if a farmer honestly stores all encoded records in the sector, they have the highest chance of success. If a farmer finds a winning chunk for the current block challenge, they perform the following steps to prove their solution is valid: 1. Identify the parent record of the winning chunk from its offset in the s-bucket. 2. Read from disk all other encoded chunks of this record. 3. Compute the corresponding proof-of-space table the same way as during plotting. 4. Query the table for proof values. 5. Decode the record by XORing it with those proofs. 6. Compute a KZG witness that the winning chunk belongs to a piece in the archived history. Finally, the farmer can propose a block with the attached solution and proof of a valid solution. # Proof-of-Time (PoT) An overview of the Proof-of-Time (PoT) chain and randomness beacon ## Overview A vulnerability of pure proof-of-stake (PoS) (and by extension proof-of-capacity (PoC)) systems lies in their susceptibility to [long-range attacks](https://doi.org/10.48550/arXiv.1910.02218). Unlike proof-of-work (PoW) systems, where block production is physically constrained by computational power, PoS/PoC systems lack this inherent limitation. In PoW, the resource is expended directly to produce a block, and only once, while in PoC the disk space “resource” is not tied to a specific block and only provides the eligibility to produce a block, reused over many blocks. Consequently, an adversary with sufficient resources could potentially rewrite a significant portion of the blockchain at any point in the chain’s history, compromising its immutability and security. This vulnerability stems from the fact that historical stake distributions can be manipulated without incurring the substantial energy costs associated with PoW systems. Additionally, PoS/PoC systems often struggle to achieve the [dynamic availability and unpredictability inherent in PoW systems](https://doi.org/10.48550/arXiv.2010.08154). The challenge lies in creating a system that can adapt to fluctuating participation rates while ensuring that block proposers remain unpredictable, thus preventing targeted attacks or manipulation. These properties are crucial for maintaining robust network operation and [security](/autonomys-network/consensus/security) against various attack vectors. The Autonomys Network addresses these challenges by implementing a separate proof-of-time (PoT) chain that interlinks with the [PoAS chain](/autonomys-network/consensus/proof-of-archival-storage). This design prevents longrange attacks by enforcing a verifiable time constraint between block proposals, analogous to the [arrow of time](https://doi.org/10.48550/arXiv.2010.08154) in PoW systems. PoT guarantees that a certain amount of wall-clock time must elapse between block proposals, preventing an adversary from rewriting history by “going back in time.” PoT is constrained physically, similar to PoW, but is not parallelizable (technically, it is proof of *sequential* work), and an attacker cannot immediately generate a successful multi-year retroactive fork even with faster hardware. The elapsed time guarantee is achieved by iterative evaluation of an inherently sequential delay function. The choice of delay function is crucial to the security and efficiency of the PoT system. After extensive analysis of existing verifiable delay functions (VDFs), we chose to employ repeated [AES-128 encryption](#user-content-fn-1)[^1]. This decision balances security, efficiency and resistance to hardware acceleration. Using the Advanced Encryption Standard (AES) leverages its extensive cryptographic research history and the availability of hardware acceleration in modern CPUs, making it an optimal choice for this application. Based on a joint study with hardware-accelerated cryptography lab Supranational, we do not expect a significant speedup over the best AES implementation, even with an ASIC. To maintain the PoT chain, the network introduces a new node role called [*timekeepers*](/autonomys-network/nodes). These nodes are responsible for evaluating the delay function and disseminating outputs. To provide PoT evaluation, timekeepers require the highest-end CPUs—unavailable to most farmer nodes. Delegating timekeeping to a separate class of nodes ensures decentralization on the consensus level, while maintaining protocol security with minimal honest participation, where the presence of at least one honest timekeeper is sufficient. To achieve asymmetric verification time for the AES-based delay function, timekeepers publish a set of intermediate checkpoints—currently 8, spaced uniformly—alongside the output. Farmers can validate each checkpoint independently and in parallel to reduce overall verification time. Including checkpoints allows other nodes to validate the output ≈ 7 times faster and use ≈ 4 times less power than evaluation by leveraging instruction-level parallelism.

Proof of Time checkpoints

The [Subspace consensus protocol](/autonomys-network/consensus) utilizes a [farming](/autonomys-network/consensus/proof-of-archival-storage/farming) dynamic that mimics the random nature of Bitcoin’s mining dynamic, while only expending a small amount of electricity. This is achieved through PoT-based block challenges for the block proposal lottery, based on *'*[*PoSAT: Proof-of-Work Availability and Unpredictability, without the Work*](https://doi.org/10.48550/arXiv.2010.08154)*'*. The PoT chain serves as a randomness beacon, providing unpredictable and verifiable inputs for block challenges, thus addressing the issue of long predictability windows often seen in protocols using generic verifiable random functions. This unpredictability is at the same level as that of PoW protocols and is stronger than those using verifiable random functions. The security of the PoT system is further enhanced by several key mechanisms. Sequentiality is achieved through output chaining between slots, ensuring that each new output depends on the previous one. To compensate for network delays, the system implements a tunable lag parameter, allowing sufficient time for propagation and verification of PoT outputs before block proposals. The Autonomys Network also incorporates measures to mitigate the potential advantage of faster timekeepers, including periodic entropy injection. To prevent manipulation of randomness, the network employs an injection mechanism similar to that used in [Ouroboros Praos](https://ia.cr/2017/573). This approach prevents attackers from controlling slot challenges by strategically releasing or withholding blocks, further enhancing the unpredictability and security of the system. ## Design challenges ### Long-range attacks Unlike in PoW, the process of block production in PoS and PoC-based blockchains is not physically constrained. This makes these protocols vulnerable to *long-range attacks*, where an attacker can very quickly produce an alternative chain all the way to the current time that can potentially be longer than the current canonical chain.

Long-range attack

To perform a long-range attack, an adversary needs to control enough resources at some point in the chain's life to rewrite a significant portion of the chain history. In PoW protocols like Bitcoin, this requires controlling over 50% of the total network hashrate for a sustained period of time. Long-range attacks are thus infeasible in practice as it takes a long time to mine an alternative chain from the past, enforcing an arrow of time. This property is key to tolerating fully dynamic honest and adversarial participation. However, long-range attacks remain a serious threat to non-PoW-based consensus protocols, including PoC (and PoS), for example: Suppose that in the first year of a blockchain's operation, all farmers were honest and collectively pledged 100 TB of storage. Suppose by the second year, the total storage pledged has reached 1 PB, out of which an adversary has dedicated 200 TB. Although at no point does an adversary control more than 20% of storage, using their 200 TB, the adversary could rewrite the chain history back to genesis by participating in all past lotteries to win blocks, and then grow a chain instantaneously from genesis to surpass the current longest chain. This is possible because the adversary's resources are significant enough to win a disproportionately large number of past lotteries relative to their share of total storage. Such a long-range rewrite seriously threatens the security and immutability of the chain history. ### Dynamic availability and unpredictability Alternative consensus protocols like PoS and PoC strive to replicate the dynamic availability and unpredictability of PoW. Dynamic availability refers to the capacity of a blockchain network to maintain robust operation in environments where nodes may join or leave dynamically, while unpredictability refers to the inability of any node to predict the next block proposer. These properties are important for the security and liveness of the network. Permissionless PoW remains the most robust method for achieving consistent availability and unpredictability in a decentralized system (evidenced by Bitcoin's continuous availability for over a decade despite a constantly varying hashrate due to miners joining and leaving the network). Protocols using generic verifiable random functions to elect block proposers usually do not achieve unpredictability at the same level, and may suffer from a long predictability window of block challenges. ## Autonomys' solution The Autonomys Network utilizes a proof-of-time (PoT) chain interconnected with the PoAS consensus chain to prevent long-range attacks and achieve dynamic availability and unpredictability. This is based on the paper [PoSAT: Proof-of-Work Availability and Unpredictability, without the Work](https://arxiv.org/abs/2010.08154) by Soubhik Deb, Sreeram Kannan and David Tse. The PoT chain addresses long-range attacks by enforcing an arrow of time similar to PoW, guaranteeing that a certain amount of wall-clock time must elapse between block proposals, thus preventing an adversary from rewriting history by "going back in time". Similar to PoW, PoT is constrained physically, however, it is not parallelizable (as its technically proof-of-*sequential-*work), preventing an attacker from immediately generating a years-long fork even with faster hardware. The elapsed time guarantee is achieved by iterative evaluation of an inherently sequential function. The output of such a function is unpredictable and is used to build a randomness beacon for block challenges. The PoT-based randomness beacon guarantees that block challenges, and hence block proposers, are not predictable, and is stronger than using verifiable random functions. This allows PoAS-based farming to achieve the same unpredictability as PoW-based mining, while using only a fraction of the electricity, ensuring fairness for all participants. ### Timekeeping [Timekeeper nodes](/autonomys-network/nodes) maintain the PoT chain, evaluating the delay function, and announcing the outputs to other nodes. A single honest timekeeper is sufficient for the security of the protocol, but there should ideally be multiple timekeepers running concurrently for robustness and decentralization. Although running a timekeeper is currently unincentivized, independent timekeeping contributes to stable block production, which benefits all network participants. Farmers and operators can also be timekeepers, however, operators are better suited to timekeeping as they already possess the necessary powerful hardware. Timekeeping fully consumes a dedicated CPU core, and should thus be run on a separate last generation machine with no other processes. This setup allows for optimal performance and secures the protocol against malicious timekeepers. The genesis of the PoT chain was concurrent with the [genesis](/autonomys-network/consensus/genesis) of the PoAS consensus chain. The input to the first slot was a random seed publicly announced at launch to ensure equal opportunity. For each subsequent slot, the output of the previous slot serves as the input. By chaining the outputs, the timekeepers enforce sequentiality and prevent skipping ahead in time. ### Randomness beacon The Subspace Protocol uses the sequence of random values provided by PoT evaluation as a source of randomness—or randomness beacon—for consensus block challenges. As Autonomys targets one block challenge per second, we set the delay function evaluation to output a proof every second. For every time slot, timekeepers evaluate the delay function for a set number of iterations to generate fresh global randomness before announcing the output to the network. This is then used by farmers to determine the next block proposer.
Farmers receive and verify these outputs before scanning their plots for any chunks of history close enough to the challenge threshold to claim the block. If they have stored the correct chunks, the farmer provides a proof-of-space for them, proposes the block, and earns rewards. The randomness is revealed a few slots in advance to ensure every farmer on the network has enough time to receive it, scan their plots, and submit their proof-of-space (if they win). Farmers' inclusion of PoT outputs in block headers integrates the PoT chain with the PoAS consensus chain. Every 50 blocks, entropy from the consensus chain is injected back into the PoT chain by using the farming solution and PoT output from a deep consensus block header as the new input for the delay function. Injection prevents an adversary from simulating a consensus chain fork without also simulating a PoT chain fork. Forks in the consensus chain will result in a different sequence of PoT outputs, hence, an attacker that forks the chain at some historical point will have to also physically run the PoT algorithm. ### AES-based delay functions The Autonomys Network uses repeated AES-128 encryption as an alternative to existing verifiable delay functions (VDFs), such as repeated squaring in groups of unknown order, as AES fulfills our requirements of being iterative and non-parallelizable, and producing a short, random, verifiable output. AES was chosen following an extensive study of existing VDF constructions owing to its research maturity and extremely efficient hardware and software implementation using hardware acceleration instructions. Based on a joint study with [Supranational](http://supranational.net/), we do not expect a significant speedup over the best AES implementation, even with an ASIC. Timekeepers publish a set of intermediate checkpoints—currently 8, spaced uniformly—alongside their output to achieve asymmetric verification time for the AES-based delay function. Farmers can validate each checkpoint independently and in parallel to reduce overall verification time. Including checkpoints allows other nodes to validate the output \~7 times faster and use \~4 times less power than evaluation by leveraging instruction-level parallelism. The target number of iterations is currently set to \~183 million with the aim of achieving approximately 1 second per time slot on high-end CPUs. Autonomys will continuously monitor hardware capabilities and adjust the target to maintain approximately 1 second slots as needed. It is crucial to benchmark the delay function on the best available hardware to ensure that no one can gain an advantage by evaluating the delay function faster than others to predict future randomness outputs. ### Security The security claim for the PoT chain: As long as there is at least one honest timekeeper online at all times, and network delay is bounded, all honest nodes can determine the correct PoT output, and hence the correct slot challenge. This is achieved by carefully implementing or accounting for: 1. **Sequentiality**: The randomness beacon achieves sequentiality by chaining slot outputs, where each output is used as an input to the delay function for the next slot. 2. **Network delay**: Farmers receiving PoT outputs for challenges immediately start auditing their plots (and proving if they have a winning solution), but can only submit the solution after 𝑟 slots. This lag parameter 𝑟 is currently set to 4 slots to ensure there is enough time to propagate, verify the PoT output, and prove a solution on common farmer hardware. Increasing 𝑟 grants an honest node more time to solve challenges, but also allows a malicious node more time to attempt to plot on-the-fly. 3. **Faster timekeepers**: The Autonomys Network addresses the potential risk of an attacker running a timekeeper node on hardware faster than all other timekeepers via several mechanisms: 1. Speed gains are not cumulative over time: because of entropy injection every 50 blocks (\~5 min), the attacker's advantage is reset. 2. If a faster timekeeper gossips their PoT to the network, other timekeepers will continuously sync to catch up to them. If a faster timekeeper withholds PoT, only using it to produce blocks on their own, although they do have some prediction window (depending how much faster they are), they either need a significant percentage of the network's disk storage or to attempt on-the-fly plotting, both of which are near-impossible (as described in [Security](/autonomys-network/consensus/security)). A faster PoT also makes long-range attacks more feasible, but an attacker is still subject to the above restrictions. We will continuously monitor the rate of PoT progression in comparison to real wall-clock time to detect for any faster timekeepers. 4. **Difficulty adjustments**: The iteration count for the PoT delay function is benchmarked to be as close to real wall-clock time as possible. With improvements in hardware, faster honest timekeepers can be deployed and the iteration count increased to account for this. 5. **Predictability**: Attackers can only predict slot challenges in advance if they have a faster timekeeper, and even then, they only last until the next injection. 6. **Biasing randomness**: Attackers cannot control the slot challenges of the next time interval by releasing or withholding their blocks from the current interval via the injection mechanism (see [Ouroboros Praos](https://eprint.iacr.org/2017/573.pdf) for a security proof). [^1]: While AES is not technically a VDF, as encryption (proving) and decryption (verification) take the same number of CPU cycles, it can be used as a VDF in practice by parallelizing verification. # Security An overview of Subspace Protocol security As a complex system, the Autonomys Network has several potential attack vectors—some are general blockchain-related vulnerabilities, while others target Proof-of-Capacity (PoC)/Proof-of-Archival-Storage (PoAS) consensus chains specifically. The Subspace Protocol addresses these attack vectors via a number of mechanisms. For a detailed security analysis, refer to our paper '[*Dilithium: A Proof-of-Archival-Storage Consensus Protocol for Subspace*](https://github.com/subspace/consensus-v2-research-paper)'. ## Security against general blockchain attacks ### Grinding on block challenges To prevent grinding on block challenges, the Subspace Protocol draws unique, unpredictable challenges using the [Proof-of-Time (PoT)](/autonomys-network/consensus/proof-of-time) chain. In PoW-based blockchains, block challenges come from the previous full block. PoC/PoAS-based blockchains cannot follow this approach, as changing the block content does not affect proof-of-space validity. Progression on the Autonomys Network consensus chain is instead based on 'time slots', each associated with a run of the PoT algorithm, the output of which is used to draw the block challenge for that slot. By design, grinding on PoT is extremely hard. ### Costless simulation attacks To mitigate against costless simulation attacks, where attackers are able to create an outsized number of blocks in proportion to their pledged disk space, the Subspace Protocol implements correlated randomness in block challenges. Using the c-correlation method, where challenges for 'c' blocks are correlated and deterministic, an attacker attempting to simulate many potential forks gains significantly less power, as the ability to maneuver across these forks becomes increasingly limited as 'c' becomes larger. ### Bribing attacks To prevent potential issues like bribing attacks that arise with the correlation of block challenges, and the predictability window associated with c-correlation in general, the Subspace Protocol uses PoT outputs to draw block challenges. This means block challenges are not known in advance and only revealed when the timeslot arrives, even though the challenges for 'c' blocks are deterministic. ### Long-range attacks To prevent long-range attacks, the Subspace Protocol integrates PoT as a fundamental component. This means that an attacker attempting to bootstrap a competing and longer (i.e. heavier) chain cannot do so without cost, as they must show that sufficient time has passed for the lifespan of this fork. In other words, as in PoW, an attacker needs to spend an infeasible amount of sequential work to maintain an attack. ## Security against PoC/PoAS attacks ### Time-memory algorithms (plot compression) To prevent attacks on PoAS consensus, the Subspace Protocol applies a masking function during farmers' plot creation. This function—described in '[*Beyond Hellman's Time-Memory Trade-Offs with Applications to Proofs of Space*](https://eprint.iacr.org/2017/893)'—is designed such that the gain in trading computation (time) over storage (memory) is very small. ### On-the-fly plotting To prevent farmers from creating plots on the fly after seeing a challenge, the Subspace Protocol is designed with two properties in mind: 1. The masking function is memory-hard. This means that creating a plot is constrained by the amount of memory the farmer has, as well as the rate of the memory IO operations it can perform. 2. Creating plots on-demand is uneconomical, and thus irrational. Due to the different resource requirements of running the masking function, the cost of running it to simulate a sufficiently large amount of storage is significantly higher than the cost of purchasing the same amount of storage, plotting it, and maintaining a farmer. In other words, a rational farmer willing to spend the cost for on-demand plotting is better off spending this cost on 'real' plotting. # Distributed Storage Network (DSN) An overview of the structure and features of Autonomys' distributed storage network Autonomys Network chain data is distributed to [farmers](/auto-suite/spaceacres-cli/farmers) for storing and serving as pieces of the blockchain history via our distributed storage network (DSN). Autonomys introduces a DSN to ensure all chain data is permanently stored in a load-balanced, fault-tolerant, and efficiently recoverable manner across all farmers (no matter how large it grows), and the consistency of storage over time, given the heterogeneous storage capabilities of farmers. Our DSN design guarantees the following properties: * *Permissionlessness*: The system operates without central coordination, accounting for dynamic farmer availability and non-uniform growth of historical data over time. * *Retrievability*: Both full and single-piece retrieval are facilitated, with requests balanced evenly across all farmers, ensuring that the overhead of serving history remains negligible. * *Verifiability*: Farmers are not required to synchronize or retain the full history, yet the system remains efficiently verifiable. * *Durability*: The probability of any single piece being lost, whether through accidental or malicious means, is minimized. * *Uniformity*: On average, each piece is stored an equal number of times across the network. These features enable the historical data to expand beyond the storage capacity of any individual farmer, while allowing farmers to allocate storage resources according to their individual capabilities. The Autonomys Network DSN is comprised of multiple distinct layers that together serve historical data pieces to requesting [nodes](/autonomys-network/nodes), with each layer contributing to different aspects of data availability, durability and efficient retrievability. This multi-layered approach was developed to balance security and performance, and interestingly, bears similarities to other recent data availability solutions developed independently from our approach, such as [Tiramisu](https://doi.org/10.48550/arXiv.2308.07163).

Distributed Storage Network

## Developers Developer documentation for building on the DSN is available on the [Autonomys Developer Hub](https://develop.autonomys.xyz/). Auto Drive API documentation is available [here](https://mainnet.auto-drive.autonomys.xyz/api/docs). ## (L3) Content delivery network (CDN) The topmost layer of our DSN is a content delivery network (CDN) designed for optimal performance under optimistic network conditions. The CDN layer (operated by a large permissioned network of nodes) significantly enhances retrieval speed and provides robust performance under normal network conditions. This layer provides web2-like performance for data retrieval: * Farmers upload newly created pieces to the CDN. * Nodes can quickly retrieve pieces from the CDN (similar to downloading from a web2 streaming service). * The CDN serves as an ultra-fast channel for passing messages between nodes, facilitating the rapid collection of data pieces. ## (L2) Pieces cache The pieces cache layer is designed to facilitate efficient piece retrieval for data reconstruction and farming. Its primary function is to minimize retrieval latency. While retrieval from archival storage necessitates computationally intensive decoding by farmers—taking approximately 1 second on consumer hardware—L2 retrieval is near-instantaneous due to the storage of unencoded pieces in the disk cache. The L2 cache utilizes a distributed hash table (DHT) to store pieces based on the proximity of the piece index hash to the peer ID. Farmers, being the most suitable candidates for L2 storage, allocate a small percentage of their pledged storage for this purpose. The overall storage network replication factor determines the number of farmers storing each piece. The piece cache layer population process is as follows: 1. Nodes generate new segments of pieces during the archiving process. 2. These new segments are temporarily stored in the node’s cache. 3. Farmers receive the newly archived segment index from the latest block header. 4. Farmers compute the piece index hashes within the segment and determine which pieces to pull to their L2 based on hash proximity to their peer ID. 5. Relevant pieces are then pulled to the farmer’s local L2 cache. In the rare case that a specific piece cannot be retrieved to the L2 cache, the farmer will attempt to decode the required piece by requesting its neighboring pieces by index and erasure decoding it from that set. If this fails, the farmer will next attempt L1 retrieval. ## (L1) Archival storage The archival storage layer is the fundamental layer responsible for the permanent storage and durability of all chain data. It comprises all storage pledged by farmers for storing encoded pieces of chain history, also known as plots. This layer provides the highest level of security against powerful adversaries, albeit at the cost of performance. Functioning as ‘cold storage’, the archival storage layer ensures the availability of history pieces in the rare event of an L2 cache miss. However, retrieval from archival storage is resource-intensive and time-consuming; thus, it is utilized only when L2 retrieval fails. Typically, the L1 layer of farmers is populated with pieces received from L2. The archival storage layer population process is as follows: 1. The farmer decides how much storage to allocate to the network. 2. Based on the amount of storage pledged, the farmer pseudorandomly and verifiably selects enough pieces of history to fill that space. 3. The farmer pulls the selected pieces from the L2 or L1 of other farmers. 4. The farmer masks the pieces as described in the plotting protocol. 5. Every time a new segment is archived, the farmer runs a check to see whether they need to replace any pieces. The last step is necessary to ensure that new history gets replicated uniformly across many farmers in the network, regardless of how long they have been participating in the network or how long ago they initialized their plots. This plot expiration is set up such that the farmer gradually replaces subsets of pieces in the plot as the history of the chain grows. On average, by the time the history has doubled in size, as compared to when the plot was initialized, half of the farmer’s plot will have expired and been replotted. By the time the history quadruples, the farmer will have replotted their whole plot once over. The choice of gradual expiration instead of full farm replots ensures maximum uptime of the farmers’ archival storage layer for serving pieces to the DSN. ## Cache types Separately from the above cache layers, we distinguish the following types of cache: * *Node cache*: Contains newly created pieces from the most recent archived segments. It is limited to a few recent segments and progressively replaces older pieces with new data. * *Farmer cache*: Contains pieces in the L2 cache, automatically populated upon receipt of new archived segment announcements. Pieces are cached according to their proximity to the farmer’s peer ID. * *Object cache*: Contains recent and popular user-uploaded objects and their mappings to pieces. To incentivize the farmer network to maintain the desired replication factor for historical data, Autonomys implements a novel algorithm that dynamically adjusts the cost of on-chain storage, or *blockspace*, in response to fluctuations in storage supply and demand. # Decoupled Execution (DecEx) An overview of Autonomys' decoupled execution framework and domains ## Overview The Autonomys Network decouples consensus from computation by separating transaction execution into independent environments (*domains*) run by [operator nodes](#operator) pledging sufficiently powerful hardware and staking $AI3. Transactions and smart contract calls from Autonomys dApps and Auto Agents are executed on these domains. Operators are incentivized through [execution fees](/autonomys-network/rewards-and-fees) (similar to Ethereum gas fees). [Domains](/autonomys-network/decoupled-execution/domains) are essentially built-in rollups that support any conceivable state transition framework and smart contract execution environment, making deploying a domain as easy as deploying a smart contract. They allow builders to easily launch their own network without bootstrapping a new validator set, while still benefiting from the shared security and interoperability provided by the Autonomys Network consensus chain. Our decoupled execution system allows for significant scalability improvements over monolithic execution environments (like Ethereum) by independently scaling transaction throughput and storage capacity. It preserves the security properties of the Nakamoto consensus, even in the presence of a dishonest majority of operators, given an honest majority of farmers on the [consensus layer](/autonomys-network/consensus). Our approach provides a unique solution to the challenges faced by storage-based blockchains, offering a balance between permissionless farming and permissioned staking. Unlike hybrid PoC/PoS consensus mechanisms employed by other storage-based blockchains, Autonomys’ system clearly distinguishes between a permissionless [farming](/autonomys-network/consensus/proof-of-archival-storage/farming) mechanism for block production and a permissioned [staking](/autonomys-network/decoupled-execution/staking) mechanism for block finalization. By simultaneously addressing the farmer’s dilemma, verifier’s dilemma, and blockchain bloat issues, the Autonomys Network presents a comprehensive solution to several critical challenges in the web3 industry, at the same time as making blockchains more energy-efficient, egalitarian and decentralized, and maintaining the security and functionality necessary for complex [smart contract](/autonomys-network/decoupled-execution/domains/auto-evm) and [application development](/auto-suite/auto-sdk). ## Design challenges It is safe to assume that rational farmers will seek to dedicate all their available disk space to consensus and expend as little computation as possible, while remaining on the longest valid chain, meaning they must compute all intermediate state transitions and maintain the state. As the burden of maintaining the state and computing transitions grows larger, both the farmer’s and verifier’s dilemmas present themselves, leading economically rational farmers to sacrifice security for higher rewards at a lower cost, by either becoming light clients or joining a trusted farming pool. ## Autonomys' solution To resolve these dilemmas, we implement a method that relieves farmers of this burden, while still allowing them to be certain they are extending the longest valid chain. Critically, this method does not degrade the liveness, fairness, or safety of block production. Our solution follows the classic technique in distributed systems of decoupling consensus and computation. In this system, farmers are solely responsible for providing subjective and probabilistic consensus over the ordering of transactions. A separate class of executor nodes—operators—computes the objective and deterministic result of that ordering. Operators are selected through a stake-based election, separate from block production, analogous to the block finalization technique proposed by [Casper FFG](https://doi.org/10.48550/arXiv.1710.09437). They are incentivized by transaction fees shared with farmers, and held accountable through a system of non-interactive [fraud proofs](https://doi.org/10.48550/arXiv.1809.09044) and [slashing](https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm). This approach, while influenced by [Flow](https://doi.org/10.48550/arXiv.1909.05821) ([see](https://doi.org/10.48550/arXiv.2002.07403) [also](https://doi.org/10.48550/arXiv.1909.05832)), is simpler (using two, not four, classes of nodes), retains compatibility with Nakamoto consensus, and maintains the ‘honest *majority* of farmers’ and ‘honest *minority* of operators’ security assumptions. It also draws inspiration from [Truebit](https://doi.org/10.48550/arXiv.1908.04756), recognizing that optimistic off-chain computation with fallbacks to on-chain verification could realize a trustless decentralized mining pool. Unlike protocols such as [ChainSpace](https://doi.org/10.48550/arXiv.1708.03778) and [LazyLedger](https://doi.org/10.48550/arXiv.1905.09274), which achieve decoupling by delegating computation to clients, our system retains global state, allowing for cross-contract calls and composability of applications. Under the decoupled execution (DecEx) framework, farmers only confirm the availability of transactions and provide an ordering, while secondary networks of staked operator nodes execute the transactions and maintain the resulting chain states. DecEx separates the probabilistic process of coming to a consensus over the ordering of transactions from the deterministic process of executing these ordered transactions. The decoupling of these roles permits alternative hardware requirements for different node types, allowing us to keep farming lightweight and open to anyone, while also providing a foundation for scaling execution both vertically—based on the hardware capabilities of operators—and horizontally—by partitioning operators into different namespaced execution domains.

Domain transaction flow from submission to fee distribution

## Contents Read the following subsections for technical details of decoupled execution, domains, staking and the Auto EVM: 1. [Domains](/autonomys-network/decoupled-execution/domains) 1. [Taxonomy](/autonomys-network/decoupled-execution/domains/taxonomy) 2. [Auto EVM](/autonomys-network/decoupled-execution/domains/auto-evm) 3. [Cross-Domain Messaging (XDM)](/autonomys-network/decoupled-execution/domains/cross-domain-messaging-xdm) 2. [Staking](/autonomys-network/decoupled-execution/staking) ## [Domains](/autonomys-network/decoupled-execution/domains) While conceptually similar to rollups on Ethereum, such as Optimism, DecEx domains differ heavily in their protocol implementation. Unlike Ethereum, the Autonomys Network does not have a global smart contract execution environment within the core protocol. Instead, DecEx is enshrined within the semantics of the core protocol itself. Despite being implemented at the protocol level, DecEx domains are still able to provide rollup protocol designers with a flexible system capable of supporting any state transition integrity framework for verifying the receipt chain, including optimistic fraud proofs and zero-knowledge proofs. Domains support any smart contract execution environment that can be implemented within the Substrate framework, including the Ethereum Virtual Machine (EVM) and Web-Assembly (WASM). Domains are the logical extension of the basic DecEx framework, taking it from a single, monolithic execution environment to a modular, interoperable network of namespaced execution environments. Each domain is its own programmable layer-2 rollup, or configurable application-specific blockchain (app-chain), that relies on the consensus chain for consensus, decentralized sequencing, data availability, and settlement. However, a smart contract, (super) dApp, or agent can use multiple domains to achieve a complex task, enabled by our unique cross-domain communication. ## [Roles](/autonomys-network/nodes) ### Farmer In our DecEx model, users submit execution transactions directly to operators, who pre-validate and batch these transactions into bundles through a (probabilistic) stake-weighted election process. These bundles are then submitted to farmers, who treat them as base-layer transactions. Farmers only verify the proof-of-election and ensure the data is available, before batching bundles into blocks in the usual manner. When a farmer finds a PoAS solution that satisfies the storage audit, they order valid transactions into a new block, committing to the last valid state root proposal they observe. Unlike on Ethereum and most other L1s, farmers do not need to maintain the code, state or account balances for contracts, only the smaller set of balances and nonces for externally owned accounts (EOAs), and minimal information about each domain runtime, staked operators, and execution receipt (ER) chains. The farmer network effectively provides decentralization-as-a-service to the domains. ### Operator Operator nodes maintain the full state of their respective domain and execute transactions, returning new proposed state roots. For each new block, a small constant number of operators are chosen through a stake-weighted election. Execution transactions from the block are then ordered deterministically, using a secure cryptographic shuffle based on the unique PoAS produced by the farmer. Operators execute the transactions according to this ordering, and produce a deterministic state commitment in the form of an execution receipt, incrementally committing to intermediate state roots. These state commitments are then included in the next bundle, forming a deterministic receipt chain tracked by all farmers within the consensus chain protocol. The initial, default implementation of DecEx employs an optimistic fraud-proof validation scheme. ## Decentralized sequencing Once the bundled transactions are included in the consensus block by farmers, domain operators must execute them in a deterministic order based on a verifiably random seed from the consensus chain. This absolves the operators of the responsibility of sequencing user transactions, while also preventing them from harvesting the maximal extractable value (MEV) and causing economic harm to users. Bundled transactions from a domain are opaque to the farmer block proposer as the latter does not have the domain state. Thus, the farmer cannot participate in MEV extraction either. Neither the order in which the operator batches the transactions in the bundle nor the order of bundles in the consensus block influences the final sequencing for execution. ## Liveness To retain liveness in case of network asynchrony or byzantine actors, operator elections are re-run for each new time slot. This allows newly elected operators to include past ERs to catch up. The election threshold dynamically adjusts based on observed operator availability. Each domain may specify the frequency of re-election based on its own needs and demand, without interfering with the liveness of other domains or the consensus chain. ## Fairness Fairness is preserved through a fair compensation mechanism between farmers and operators. Farmers are compensated for their blockspace at the current price of storage, by rewards, and for their work of including the domain bundles, by the operators. Operators are compensated for the blockspace costs incurred if their ERs are valid, and for their work of bundling and executing user transactions, via transaction fees. ## Validity Validity is ensured through a system of fraud proofs. Within the challenge period, any honest node which operates on a domain can compile a fraud proof for an invalid state transition performed by another operator on that domain. The fraud proof can be verified by any consensus node without having the whole domain state. If it is valid, the operator who proposed the invalid ER will have their entire deposit confiscated. Any operator who has extended the invalid ER is also slashed as punishment for dishonest or lazy behavior. ## Finality Transactions on optimistic domains are subject to a challenge period until they are settled on the consensus chain. During the challenge period, nodes can dispute the correctness of state transitions presented by operators. Any node that has an up-to-date state of the domain can submit fraud proofs for this domain and does not need to be a staked operator to do so. Whether the node is acting honestly or not in this particular instance is determined by the validity of the fraud proof. Currently, the challenge period on domains is 14400 blocks, or approximately 1 day. Fast finality is possible for services that run their own honest operator nodes. Since the operator nodes execute all the state transitions, they can be certain about the correctness of the domain state at any given time. ## Safety Safety is maintained by distinguishing between illegal and invalid transactions. Farmers enforce legality by ensuring transactions have valid signatures and can cover the specified fees. Operators enforce validity by executing transactions deterministically in the order specified by farmers. ## Network dynamics Our system is able to account for network delays and stochastic block production. Operators are incentivized to generate fraud proofs locally to release their own ERs as soon as possible, speeding up fraud-proof propagation and strengthening security guarantees. Farmers order by urgency and deduplicate fraud proofs in their mempool to ensure timely inclusion. ## Adversarial scenarios The system is designed to handle various adversarial scenarios, including attempts to attack the liveness of execution or confuse farmers about transaction legality. Even in the presence of a dishonest majority of operators, the system remains secure as long as a single honest operator remains connected to an honest farmer within their peer set. Operators are incentivized to reveal fraud to protect their own stake and claim their share of the rewards, while they are punished for extending an invalid ER without first demonstrating fraud.

Domains

# Domains An overview of Autonomys domain sub-protocols ## Workflow ### Domain creation To create a domain, a developer registers and uploads the domain runtime to the chain state, before instantiating the domain on the registered domain runtime. The domain instantiation process includes a genesis config for specifying variables including the domain name, runtime code, maximum block size and weight, and number of bundles in each slot and block (from which the chainspec and genesis block for the domain are built). ### Operator staking Operators can begin participating in leader elections to produce domain bundles and execute blocks by submitting a registration extrinsic with a staking deposit to a domain. This will add them to the domain's Operator Registry and allow them to participate in the leader election at the next stake epoch. Nominators can then begin staking $AI3 to those operators. ### Domain transactions Users can start producing extrinsics (transactions) and submitting them to domains once an operator has joined the domain. When pre-validating extrinsics, operators only check to ensure the extrinsic is well-formed and that the user can afford the blockspace storage fee. They do not yet attempt to execute the transaction (which will determine whether the execution weight fees can be paid). ### Leader election For each time slot, all registered operators attempt to solve a VRF puzzle for leader election (with a success probability defined in the domain genesis config) by signing the slot challenge and checking if the result is below the desired threshold. The elected operator gathers transactions from the pool and produces a new domain bundle. ### Bundle production To produce a new bundle, an operator must include: * a proof of election showing that they are a leader for this time slot * an execution receipt that either extends or confirms the previous domain block tracked on the consensus chain * all bundle extrinsics that fall within the operator's portion of the extrinsic pool * storage fees for the bundle extrinsics If all is provided, the bundle is broadcast on the consensus chain gossip network. ### Bundle verification All consensus (farmer) nodes receiving the bundle verify that it is well-formed. The bundle header should include a valid proof of election based on the stake distribution for the relevant epoch, and the execution receipt should build on the current execution chain block tree for this domain. Consensus nodes broadcast all valid bundles to their peers and place them within their local extrinsic pool. ### Bundle inclusion in the consensus block Once a consensus node is elected to produce a new consensus chain block, it includes as many valid domain bundles as will fit into the block, before broadcasting the block to the consensus network. Other nodes will only accept blocks that include valid bundles. ### Domain block execution Operators can build and execute domain blocks with the corresponding valid consensus block (if it contains at least one domain bundle). On block execution, each bundle header is applied to the consensus chain state, and each extrinsic is added to the domain's execution inbox. Extrinsics are deduplicated, grouped by sender, and deterministically shuffled to mitigate the ability of operators to extract value from users by re-ordering or inserting extrinsics (MEV). The domain block is then carefully executed, one extrinsic at a time, allowing the operator to produce an execution receipt. ### Challenging operators Any node that observes an execution receipt within a bundle of any consensus chain block that differs from what they produced locally, produces an extrinsic with a fraud proof to handle this detected fraud. If the fraud proof is valid, it will be included in the consensus chain, which will prune the execution receipt in question and all children from the block tree, and slash all related operators. Currently, the challenge period is 14400 domain blocks (\~1 day). ### Domain block fees A domain block is considered confirmed and can no longer be disputed when its challenge period ends. Domain block fees are made up of execution and storage fees as well as tips included with the block's transactions. After a domain block is confirmed, the total fees for the block are applied as follows: * The storage fees of the confirmed block are refunded to the operators that authored bundles in the block according to the respective storage sizes of their bundles. * The execution fees of the confirmed block are added to the current epoch fees for the relevant domain, and split equally between the pools of operators that submitted the execution receipt for the block. The current epoch fees are noted in the Operator Registry until the epoch transition. All fees are auto-staked to the pools' stakes at the end of the current epoch (see [Staking](/autonomys-network/decoupled-execution/staking#staking-epochs) for more details on staking epochs). * Operators receive a share of all fees earned by their pool (as per the nomination tax specified in their operator config). This is automatically re-staked to each operator at the next epoch transition, and operator shares, total pool shares, and total stake are updated (see [Staking](/autonomys-network/decoupled-execution/staking#example) for an example share calculation). * The domain applies all changes related to fees and (un)staking to operators at the next epoch transition (note that this only changes the total pool balance and does not affect individual nominator shares).

Domain transaction flow from submission to fee distribution

## Permissionlessness * **Creating** **a domain** is *permissionless.* * **Staking** and **nomination** are *permissionless*, meaning operators and nominators can freely stake and unstake across different domains. * **Operating** on most domains is *permissionless* provided the prospective operator has the required funds for the minimum stake (MinStake). Some domains may choose to restrict who can operate on them via an allowlist, but this is not the default. * **Opening a cross-domain messaging channel** must be allowed by both domain owners. * **Registering a new runtime** to create a non-WASM, EVM or Substrate-based domain is permissioned, requiring protocol governance approval. # Taxonomy A comparison of different ecosystem rollup architectures ## Standard rollups Standard rollups (on Ethereum) are validated and settled through smart contracts. ## Sovereign rollups Sovereign rollups (on Celestia) leverage the base layer protocol for consensus and data availability. ## Enshrined rollups Enshrined rollups ([domains](/autonomys-network/decoupled-execution/domains) on Autonomys) are directly integrated into the core consensus protocol of the underlying blockchain, ensuring the rollup's features and functionality are maintained and enforced by the network's consensus rules. This built-in support enhances the rollup's security, interoperability and adoption, while providing the benefits of a typical rollup, such as increased throughput and reduced transaction fees. Domains extend Celestia's sovereign rollup model to include shared settlement by default by allowing operators to re-stake (as proposed by Free2Shard and implemented by EigenLayer on Ethereum). Autonomys enshrines the re-staking model within the semantics of the core protocol (unlike EigenLayer, which is implemented through smart contracts). Although similar to Polkadot parachains, domains support a modular validation framework and permissionless deployment, unlike parachains' monolithic validation model and permissioned deployment. Domains also have shared security and trust-minimized interoperability as they are validated and settled on the consensus chain (unlike Cosmos zones and Avalanche subnets). # Auto EVM An overview of Autonomys' Ethereum Virtual Machine domain **Auto EVM** (formerly Nova EVM) is the first execution [domain](/autonomys-network/decoupled-execution) launched on the Autonomys Network. As a permissionless instance of the Ethereum Virtual Machine (EVM), Auto EVM supports the deployment, management and execution of Ethereum transactions, smart contracts and decentralized applications (dApps) natively on the Autonomys Network. The Auto EVM domain is seamlessly interoperable with other Autonomys domains, while maintaining the unique features of an EVM-compatible environment. By deploying on Auto EVM, Ethereum ecosystem dApps and DeFi protocols benefit from significantly higher throughput, lower fees, and improved scalability. # Cross-Domain Messaging (XDM) An overview of Autonomys' novel mechanism for communication between domains and the consensus chain **Cross-domain messaging (XDM)** enables seamless, secure and trustless communication between [domain](/autonomys-network/decoupled-execution) chains and the Autonomys Network [consensus](/autonomys-network/consensus) chain at the protocol level by creating standardized, verifiable cross-chain pathways for sharing data, assets, and messages. XDM allows Autonomys' modular architecture of specialized components to interoperate efficiently, while preserving their separation for optimized scalability, security and decentralization. This facilitates the development of scalable dApps built across multiple domains, and the creation of a cohesive and intuitive Autonomys ecosystem. Further technical information is available in our [protocol specs](https://github.com/subspace/protocol-specs/blob/main/docs/decex/xdm.md). ## Components ### Channels Channels are secure, dedicated communication pathways between domains or between a domain and the consensus chain. Each endpoint pairing has a uniquely identifiable specialized channel, ensuring clear and precise message routing. Once a channel is opened, it is responsible for maintaining message order, security checks, and reliability throughout its lifetime. #### Channel Management and Security * **Channel Opening:** A financial deposit is required to establish a channel, deterring misuse and denial-of-service (DoS) attacks by making malicious activities economically infeasible. * **Channel Closure:** Channels can be closed by either domain through a secure, protocol-driven message. Closure ends communication immediately, preventing further exchanges. ### Messages Messages are packets of information that travel along channels. They may represent asset transfers, state changes, or simple communications between dApps running on separate domains. Each message includes clear information about the: * **Sender**: The origin domain and application initiating the communication * **Recipient**: The destination domain and application receiving the communication * **Payload**: The data or instructions being transmitted By carrying structured information, messages ensure clarity and accountability at every step. ## Workflow 1. **Channel Initialization:** A domain or application requiring cross-chain communication initiates a new channel via a handshake process where both sides recognize and trust the channel for future messaging. 2. **Message Submission:** Once a channel is opened, applications can submit messages to the domain's runtime. The domain securely records these messages in its internal state, preparing them for inclusion in the next block. 3. **Message Commitment & Relaying:** The domain's runtime includes the committed messages in a new block, which is then relayed securely to the consensus chain. 4. **Consensus Chain Verification:** Upon receiving the block, the consensus chain verifies the messages' authenticity, and confirms the channel, sender and recipient details are accurate. 5. **Challenge Period:** The challenge period is a brief security window during which validators and participants ensure no discrepancies or malicious activities have occurred, providing robust security guarantees. 6. **Dispatchment & Delivery:** After successfully passing the challenge period, the consensus chain securely dispatches the messages to their intended recipient domain via the previously established channel. 7. **Acknowledgment and Response:** Upon receiving a message, the recipient domain processes it accordingly, optionally sending back an acknowledgment or follow-up message through the same secure channel. # Staking An overview of staking on the Autonomys Network The Autonomys Network relies on staking from both domain [operators](/autonomys-network/nodes) and nominators (who are mostly farmers) to secure the network. Under Autonomys' Nominated Proof-of-Stake (NPoS) algorithm, nominators endorse operators who execute transactions and produce blocks, with operator stakes acting as nomination pools. NPoS allows all $AI3 token holders with the required minimum stake (MinStake) to participate in staking and earn a yield on their holdings, maintaining high levels of network security by increasing total value locked (TVL). A significant portion of the total $AI3 supply is likely to be staked in the NPoS system at any one time. Autonomys uses a two-tier staking model: * **Operators** stake an $AI3 MinStake to join a [domain](/autonomys-network/decoupled-execution/domains) (set by the domain creator), earning the right to produce blocks and [$AI3 rewards](/autonomys-network/rewards-and-fees) (execution fees) in exchange for validating and executing transactions, producing execution receipts, and applying state transitions. Operators set a nominator MinStake and nomination tax for their pool when they register. The nomination tax is the operator's share of the execution fees, and is automatically re-staked. Operator slot leader elections to determine block production are stake-weighted for each domain. * **Nominators** stake an $AI3 MinStake to operators (increasing their stake and chance of success in slot leader elections) and earn a share of their fees. An unlimited number of nominators can stake to an operator's nomination pool. Nominators are often farmers earning $AI3 rewards for pledging storage, but any $AI3 token holder can nominate. This system balances power between nominators/farmers and operators, with both parties sharing the operator fees and potential penalties (via slashing). As nominators can easily stake and un-stake at any time, operators are incentivized to recruit and compete for nominators by cultivating a trusted community reputation, providing good service, and offering a reasonable nomination tax, ensuring they remain accountable. Autonomys' two-tier staking structure also provides robust security guarantees by consolidating quantities of stake far exceeding the size of any one $AI3 holding, creating significant barriers for bad actors attempting to elect dishonest operators. Attacking the system would be both prohibitively expensive (as large amounts of stake would be slashed) and require considerable community trust (to attain the necessary stake), making it highly challenging for adversaries. ## Staking epochs A staking epoch is a period of time during which staking distribution remains the same. This period is currently set to 100 blocks (\~10 minutes). The end of each epoch triggers a series of events to transition to the next epoch. These events include: * allocation of fees earned for the blocks confirmed during the epoch * deposits and withdrawals of stake * operator registrations and de-registrations * recalculation of stake distribution for the slot leader election New operators must therefore wait for the end of the current epoch to register; new nominators must wait to nominate; and new stake deposits and withdrawals must wait to be processed. As soon as the end of the epoch transition is finalized, the next epoch begins. Nomination ## Nomination pools[​](https://subnomicon.subspace.network/docs/decex/staking#nomination-pools) Any $AI3 token holder with the required nominator MinStake can join an operator's nomination pool by submitting a nomination transaction with their desired $AI3 stake deposit. The workflow is then as follows: 1. The nominator's $AI3 deposit is added to the list of pending deposits in the nomination pool. 2. At the end of the epoch, the nominator's deposit is processed. 3. 20% of each nominator's deposit is reserved in the operator's storage fee fund to pay for bundles the operator creates. This does not affect the stake distribution and is proportionally refunded with each withdrawal. The remaining 80% is locked in the nominator's wallet. 4. The nominator's share of the total pool is calculated based on their deposit as a percentage of the total stake and their length of time staked. This is used to calculate the nominator's share of the operator's execution fees as follows: 1. Compute the nomination pool end-of-epoch $$shares\_per\_AI3$$ as the total number of shares divided by the sum of all stake in the pool and fees collected during the previous epoch:\ $$shares\_per\_AI3 = total\_shares/(pool\_total\_stake + fees∗(1−nomination\_tax))$$ 2. Assign the $$shares$$ to the nominator based on the $$shares\_per\_AI3$$ of the pool:\ $$shares = deposit\_amount \* shares\_per\_AI3$$ 3. Add the $$deposit\_amount$$ to the $$pool\_total\_stake$$ of the nomination pool and the domain’s total stake 4. Add the $$shares$$ of the nominator to the $$total\_shares$$ of the nomination pool Autonomys nomination pools are 'lazy'—any execution fees earned by operators are automatically re-staked to the pool, and not deposited to nominator wallets until a withdrawal request is submitted. This increases the pool's total stake and the operator's chance of producing blocks. Nominator withdrawal requests are processed at the end of the epoch, at which point the nominator's stake is removed from the pool and the domain's total stake, and they receive their share of the fees. Operators can also withdraw their stake and fees at any time by submitting a `withdraw_stake` extrinsic. To withdraw their entire stake and earned fees, an operator must deregister (as they would no longer satisfy the domain's MinStake requirements). Deregistered operators are removed from the domain, and their stake, as well as the stakes of all their nominators, are returned to their wallets. Withdrawals currently have a locking period of 14,400 domain blocks (\~1 day), after which withdrawn tokens are unlocked in users' wallets. All withdrawals requested in the same stake epoch are aggregated together, and the total amount is unlocked at once. This locking period is necessary to ensure that the domain block executing the withdrawal is confirmed and not challenged by a fraud proof, increasing the economic stability of domains. Nomination pool ## Example[​](https://subnomicon.subspace.network/docs/decex/staking#example) Operator $$O$$ has registered an operator with a nominator MinStake of 10 $AI3 and nomination tax of 5%, and staked 100 $AI3. Operator $$O$$ has 2 nominators $$N\_1$$ and $$N\_2$$​, each staking 50 $AI3. Initially, $$shares\_per\_AI3 = 1$$, so $$O$$ receives 80 shares, $$N\_1$$​ and $$N\_2$$ each receive 40 shares, and $$total\_shares = 80 + 40 + 40 = 160$$ in the stake. 20% of each deposit is reserved in a storage fee fund: $$O$$ reserves 20 $AI3, and $$N\_1$$​ and $$N\_2$$​ reserve 10 $AI3 each, for a total fund of 40 $AI3: | | $$O$$ | ​$$N\_1$$​ | $$N\_2$$​ | | ----------------------- | ------- | ---------- | --------- | | **Shares** | 80 | 40 | 40 | | **Storage fee deposit** | 20 $AI3 | 10 $AI3 | 10 $AI3 |
Total stakeTotal sharesTotal storage fee depositsStorage fee fund
160 $AI316040 $AI340 $AI3
In the next epoch, the pool earns 20 $AI3 in execution fees and is refunded an extra 4 $AI3 in storage fees. The operator takes a 5% nomination tax (1 $AI3) on the execution fees, which is automatically re-staked for 1 share, and of which 0.05 $AI3 is deposited to the storage fee fund. The pool stake is now $$160 + 20 + 1 = 181$$ $AI3; the storage reserve is now $$40+4=44$$ $AI3; and the pool end-of-epoch $$shares\_per\_AI3$$ is now $$160/(160+20\*(1−0.05))=0.893855$$. The refunded 4 $AI3 in storage fees is not calculated as part of $$shares\_per\_AI3$$, maintaining a stable stake distribution despite the fluctuating size of the storage fee fund. A new nominator $$N\_3$$​ stakes 33.6 $AI3. 6.72 $AI3 is transferred to the storage fee fund, and $$N\_3$$​ receives $$((33.6−6.72)\*0.893855)=24$$ shares. The total pool stake becomes $$181+26.88=207.88$$ $AI3; the storage fee reserve becomes 50.72 $AI3; and the total shares becomes $$160+24+1=185$$. The updated staking summary at the end of the epoch: | | $$O$$ | $$N\_1$$​ | $$N\_2$$​ | $$N\_3$$​​ | | ----------------------- | ---------- | --------- | --------- | ---------- | | **Shares** | 81 | 40 | 40 | 24 | | **Storage fee deposit** | 20.05 $AI3 | 10 $AI3 | 10 $AI3 | 6.72 $AI3 |
Total stakeTotal sharesTotal storage fee depositsStorage fee fund
207.88 $AI318546.72 $AI350.72 $AI3
Suppose that after some time, $$N\_1$$ wants to withdraw 20 shares; $$shares\_per\_AI3$$ in the pool is 0.8; and the storage fee fund balance is 52 $AI3. At the end of the epoch, the 20 shares are un-staked, and the corresponding amount of $AI3 ($$20/0.8=25 AI3$$) is deducted from the pool's total stake. The total amount of $AI3 $$N\_1$$ receives is: $$(withdraw\_shares/shares\_per\_AI3) + storage\_fee\_fund\_balance \* (storage\_fee\_deposit/total\_storage\_fee\_deposits) \* (withdraw\_shares/shares) = 25 + 52 \* (10/46.72) \* 20/40 = 30.57 AI3$$ If $$N\_1$$ wanted to withdraw all their stake and fees (40 shares), they would receive: $$(40/0.8) + 52 \* 10/46.72 \* 40/40 = 61.13 AI3$$, earning 11.13 $AI3 in fees. After waiting the locking period, the withdrawn amount is unlocked in their wallet. > *Note:* This example is intended for illustration. The actual calculations are performed with shannons $$(1 AI3 = 10^{18}$$ shannons). # Networking Protocols An overview of Autonomys' networking protocols Based on [libp2p](https://libp2p.io/), Autonomys' networking stack implements several unique protocols to handle a variety of essential tasks. ## Transaction propagation Autonomys uses a gossip mechanism to propagate transactions to peers across the network, ensuring nodes have a consistent view of unconfirmed transactions. When a node receives a new transaction, it validates the transaction and, if valid, adds it to its transaction pool, before broadcasting it to its directly connected peers. When a connected peer receives the transaction, they too validate it, retaining a copy (if valid), before sharing it with all their connected peers (excluding the one from which it was received). Consequently, the transaction disseminates from its source, spreading throughout the network, ensuring every node receives a copy. ## Block and bundle relay Autonomys introduces 'compact blocks' and 'compact bundles' relayed via gossiping to propagate new blocks and bundles across the network as efficiently as possible. As a substantial part of each block's size is the body of transactions included within it, and each transaction has previously been broadcast to nodes, rebroadcasting the entire body is unnecessary. As such, when a node receives a new block, it validates the block header and transactions, and if valid, builds a compact block message containing only the block header and transaction IDs that is then gossiped across the network. When a connected peer receives the compact block, it verifies it has all the referenced transactions in its pool, requesting the complete transactions from the broadcasting node if any transactions are missing. This optimization allows for fast block propagation while minimizing unnecessary transaction data transfer across the network. A similar mechanism is used for bundle relay, where a compact bundle contains only the bundle header and transaction IDs, allowing for rapid dissemination of new bundles throughout the network. ## Synchronization Autonomys employs an adaptive synchronization protocol to sync nodes to the latest state of the network efficiently. This adaptive protocol chooses between DSN sync and block sync based on how far the node is behind the blockchain. The distributed storage network (DSN) sync uses a specialized synchronization protocol enabled by Autonomys' unique archival and storage mechanism. The DSN sync is attempted every time a node joins the network or detects it is more than a hundred blocks behind the live network. The node first gathers information from its peers about the latest archived segment headers to verify whether any new data has been archived since it last synced. If new segments are available, it then downloads the headers, and verifies whether they form a chain. Once verified, it downloads the complete segment data from the DSN, verifies commitments, and locally reconstructs blocks from pieces. The DSN sync allows a node to sync hundreds or thousands of blocks at once by downloading archived data directly from the DSN (rather than fetching individual blocks from peers). Once a node has downloaded all missing segments and imported the archived history, it switches to syncing recent blocks from other nodes until it reaches the end of the blockchain, at which point it is live. ## Piece retrieval Autonomys implements a piece retrieval protocol that allows nodes to retrieve history pieces from the network in the most efficient way possible. When nodes need pieces for plotting, or when requested by a client application, they send requests to peers with IDs close to the required piece index hashes. With a high probability, the peers receiving the requests will have the pieces available in their piece caches and can respond with the piece data. In the rare case none of the peers have the required pieces, the request falls back to asking them to decode the pieces from their plots. # $AI3 Rewards & Fees An overview of the $AI3 token and its structure for rewards and fees ## **Introduction** **$AI3** *(formerly SSC/ATC)* is the native token used for rewards, fees, transactions, and staking on the Autonomys Network ($tAI3 on our Taurus testnet)*.* ## Rewards & fees All participants in the Autonomys Network are compensated fairly for their maintaining the network via: * **Fees**: For transactions on the Autonomys Network (by users sending transactions) * **Rewards**: For participants' work on the Autonomys Network (via the protocol's issuance of newly minted $AI3) Different participants receive their compensation through a combination of fees and rewards depending on their role. ### Farmers Farmers pledge SSD space to the network and receive $AI3 in the form of: * *storage fees* for the transactions and bundles they include in consensus chain blocks * *block rewards* for the blocks they propose (issued by the protocol) * *vote rewards* (issued by the protocol) ### Operators Operators pledge compute and a minimum stake to the network and receive $AI3 in the form of: * *compute fees* for the [domain](/autonomys-network/decoupled-execution/domains) transactions/bundles they produce, validate and execute (via a nomination tax) * *compute fees* for the [cross-domain messaging](/autonomys-network/decoupled-execution/domains/cross-domain-messaging-xdm) (XDM) messages they deliver and execute (calculated based on the processing requirements of each message on both the sending and receiving domains) * *relay fees* for the XDM messages they relay between domains The nomination tax is a commission collected by operators on nominator $AI3 fees before they are proportionally distributed to the nominators staked to that operator. Operators receive the fees for their executed transactions once the relevant domain block has cleared the challenge period. Domain transactions (e.g. EVM contract calls) are usually significantly more computationally intensive than consensus chain transactions (e.g. balance transfers), and are therefore more expensive in order to compensate operators fairly. For more details, see [domain block fees](/autonomys-network/decoupled-execution/domains#domain-block-fees). XDM compute and relay fees are collected from the sender and burned on the sending domain before being minted on the receiving domain and distributed to operators upon successful delivery and execution. ### Nominators Nominators pledge a minimum stake to an operator's nomination pool and receive $AI3 in the form of: * a share of the operator's *compute fees* for increasing the size of their pool (based on the nominator's share of the pool) $AI3 holders nominate stake to operators to increase their chances of executing and processing blocks. The larger the nomination pool, the higher the probability of producing a bundle and receiving the associated fees. Operators are thus motivated to attract as many nominators as possible to increase the size of their nomination pool. For more details on pool shares and fee calculations, see [nomination pools](/autonomys-network/decoupled-execution/staking#nomination-pools). ## Transaction fees Every transaction on the Autonomys Network has a: * **Length**: The number of bytes it consumes on the network * **Weight**: The number of picoseconds it takes a node with reference hardware to execute it Autonomys separates transaction fees paid by network participants into: * **Storage fees**: For the storage space consumed by including a transaction in a block and archiving it * **Compute fees**: For the computational resources consumed by the execution of the transaction ### Storage fees The size of the storage fee depends on the length of the transaction and the amount of available storage on the network. The formula for the storage fee is: $$storage\_fee\_per\_byte = total\_credit\_supply / total\_space\_pledged/min\_replication\_factor-history\_size \* (shannons/byte)$$ $$storage\_fee(tx)=storage\_fee\_per\_byte∗length(tx)\ shannons$$ For the purposes of storage fee calculation, the total $AI3 supply consists of all $AI3 in existence, including staked or otherwise locked $AI3. The total space pledged to the network is divided by the protocol's minimum replication factor of 50, ensuring that the network is able to reliably store all the transactions included in the consensus chain. The history size is the total size of all the blocks in the consensus chain that are archived. ### Compute/execution fees The size of the compute fee depends on the weight of the transaction and the demand on the network. Compute fees for the execution of extrinsics on the consensus chain (e.g. balance transfers) are collected by the block proposer. Compute fees for executing transaction bundles on domains are split equally between the domain operators who submitted the execution receipt (ER) containing the bundle (after the ER has cleared the challenge period). Autonomys implements Polkadot’s [slow adjusting fee](https://research.web3.foundation/Polkadot/overview/token-economics#2-slow-adjusting-mechanism) mechanism where the fee is slightly adjusted each block based on the utilization of the available block weight by normal extrinsics. The formula for the compute fee is: $$compute\ fee(tx) = adjustment\ multiplier \* compute\ fee\ per\ weight \* weight(tx)\ shannons$$ ## Dynamic issuance The issuance of the newly minted tokens by the protocol is dynamic, depending on recent demand for blockspace and a decay function that gradually reduces rewards over 40 years. This smooth reduction allows for higher rewards for early adopters, a gradual increase in the circulating supply in a more controlled manner, and an extended lifetime of issuance for the long-term viability of the chain. For more information on Autonomys' sustainable token issuance model, read our [token paper](https://www.autonomys.xyz/post/from-space-race-to-long-tail-crafting-a-sustainable-token-issuance-model-for-a-resilient-autonomys-network). For full details of $AI3 supply and distribution, read the [Subspace Foundation paper](https://www.subspace.foundation/autonomys-network-token-supply-and-distribution). # Gemini Testnets An overview of dynamic token issuance on Autonomys' Gemini testnets On Autonomys' Gemini testnets, farmers initially received 0.1 $tSSC in block rewards for the blocks they proposed, and 0.1 $tSSC for the votes they submitted. The decay function reduced rewards every block as the chain progressed following the exponential decay function: $$ reference\_subsidy = initial\_subsidy \* e^{-initial\_subsidy\*(n-decay\_block\_start)/max\_issuance\_tokens} $$ Both block proposer rewards and vote rewards were computed using the same formula. Dynamic issuance was tested on the Gemini 3h testnet where: * $$initial\_subsidy = 0.1$$ $tSSC per block * $$n$$ is the current block height * $$decay\_block\_start = 718959$$ (the block when the decay function was activated) * $$max\_issuance\_tokens = 100000000$$ $tSSC On Gemini-3h, the reference subsidy issuance decayed roughly following the curve below, starting at 0.1 $tSSC per (empty) block, and decreasing over the next 1,296,000 blocks (\~90 days).

Dynamic reward issuance on Gemini-3h

Block proposer rewards were also dynamic based on the demand for blockspace, with the protocol decreasing proposer rewards in response to increased execution fees earned by proposers (due to blockspace utilization). Blockspace demand was measured as an exponential moving average of the percentage of the maximum blockspace used by normal transactions over the last 100 blocks (excluding operational transactions like votes and fraud proofs): $$ blockspace\_utilization = \sum\_{\mathclap{}}encoded\_transaction\_size / 3.75 MiB $$ The final formula for block proposer rewards was: $$proposer\_reward = reference\_subsidy - min(reference\_subsidy, max\_block\_fees) \* blockspace\_utilization$$ Vote rewards represented 90% of the reference subsidy, and were unaffected by utilization: $$voter\ reward = 0.9 \* reference\_subsidy$$ The remaining 10% of each vote reward was received by the proposer of the block that included the vote to incentivize the proposer to include votes. # Scalability An overview of Autonomys' approach to achieving unprecedented scale Autonomys is taking a first-principles approach to scaling the Subspace Protocol that builds on existing blockchain scalability protocols, including the likes of [Prism](https://doi.org/10.1145/3319535.3363213) and [OmniLedger](https://eprint.iacr.org/2017/406.pdf), and our own novel research. ## Constraints to scaling blockchain TPS For any blockchain system, there are at least three physical scaling constraints: * The *communication* constraint—the upload bandwidth of a single participating node * The *computation* constraint—the number of transactions a node is capable of executing per second * The *storage* constraint—the number of transactions stored by each node The goal of blockchain scaling is to achieve the maximum possible throughput under these physical constraints, measured by TPS (transactions per second). In a conventional blockchain design, a participating node (often referred to as a full node or a miner) has to download, store and execute all the transactions. This requirement leads to several upper bounds. For instance, the throughput cannot exceed the average upload bandwidth divided by the average size of transactions. Thus, if the average bandwidth is 10 Mbit/s and the average size is 250 bytes, the throughput cannot exceed 5000 TPS under the communication constraint—too small for certain applications. The huge number of transactions generated by the future [Internet-of-Agents](https://davidecrapis.notion.site/The-Internet-of-Agents-23aa09799b9c4620a1a287926bcfd6af), as well as the mainstreaming of the burgeoning decentralized finance (DeFi), decentralized science (DeSci) and on-chain gaming (GameFi) ecosystems, will significantly expedite the demand for greater scalability. How can we scale the Autonomys Network throughput by 100x to be able to handle 500,000 TPS? ## Scaling the Autonomys Network In order to achieve this goal throughput of 500,000 TPS, we could increase the upload bandwidth to at least 1Gbit/s. However, this would sacrifice decentralization, as nodes with low bandwidth would no longer be able to participate. Instead, having already decoupled the requirement that every node store and execute all transactions, via our DSN and DecEx, we are now decoupling the bandwidth requirement. Inspired by the [similarities between rollup and sharding designs](https://vitalik.eth.limo/general/2024/05/23/l2exec.html), we propose a unique sharding approach based on cryptographic sortition. Our system consists of a beacon chain and multiple data shards. The beacon chain is maintained by all the farmers through the PoAS consensus algorithm. Each data shard is maintained by a subset of farmers selected by cryptographic sortition over time. For instance, a farmer could be elected as a leader for the beacon chain if they have a lottery ticket close enough to $$C\_t$$ (i.e. the distance between the ticket and $$C\_t$$ is smaller than a threshold $$T\_b$$); elected as a member for data shard 1 if the distance is no smaller than the threshold $$T\_b$$, but smaller than $$T\_b + T\_s$$; elected as a member for data shard 2 if the distance is no smaller than $$T\_b + T\_s$$, but smaller than $$T\_b + 2T\_s$$; and so on. Generally, a farmer is elected as a member for data shard $$i$$ if the distance is no smaller than $$T\_b + (i-1)T\_s$$, but smaller than $$T\_b + iT\_s$$. A farmer is only assigned to a shard when elected and is a member of at most one shard at any time. This *dynamic* shard membership is recorded on-chain as farmers prove their winning tickets. When a new domain joins, it is assigned to a data shard. A farmer elected as a leader for this shard downloads recent blocks and transaction bundles, then produces a new shard block on the longest available chain. This new block is shared with domain operators, the DSN, as well as future leaders. Its block header is shared with all the farmers through gossiping (to be included in the beacon chain). This process is a variation of Nakamoto’s longest chain protocol, and the majority of leaders in any shard are honest due to cryptographic sortition, which supports shard safety and liveness with high probability. To address data withholding attacks, where a malicious shard leader colludes with malicious domain operators, the system allows future shard leaders to detect such attacks. For rare undetected attacks, we propose an on-chain complaint mechanism similar to [Tas and Boneh (2023)](https://doi.org/10.48550/arXiv.2208.02999). This workflow is illustrated for one domain and shard below.

Data flow between domain, shard and beacon chain

Next, we present an alternative design using cryptographic sortition and erasure coding. In this setup, explicit shards are unnecessary. When a domain operator creates a transaction bundle, it broadcasts the header to all the farmers (to be included in the beacon chain) and disseminates erasure-coded chunks. Farmers receiving a chunk can vote for the bundle via cryptographic sortition, with voting data recorded on the beacon chain to facilitate consensus on data availability. This is in spirit similar to a very recent scalability design proposed in [Fisch et al. (2024)](https://eprint.iacr.org/2024/1299). # Introduction An overview of Autonomys' product suite The **Auto Suite** is our suite of products and tools for developing on and interacting with the Autonomys Network. It currently includes tooling for developing and deploying dApps ([*Auto SDK*](/auto-suite/auto-sdk)) and on-chain agents ([*Auto Agents Framework*](/auto-suite/auto-agents) & [*Auto ID*](/auto-suite/auto-id)), as well as software for running farmer and operator nodes ([*Space Acres | CLI*](/auto-suite/spaceacres-cli)), staking and block explorer ([PolkadotJS](https://polkadot.js.org/apps/#/extrinsics) and [Auto Portal](https://auto-portal-web.vercel.app/dashboard)). ## Contents This section provides an overview of our software for node running, staking $AI3 and developing on the Autonomys Network: 1. [**Introduction**](/auto-suite/introduction) 2. [**Space Acres | CLI**](/auto-suite/spaceacres-cli) 1. [Farmers | Store to Earn $AI3](/auto-suite/spaceacres-cli/farmers) 2. [Operators | Compute to Earn $AI3](/auto-suite/spaceacres-cli/operators) 3. [Block Explorer And Staking Interface](/auto-suite/block-explorer-and-staking-interface) 1. [Nominators | Stake to Earn $AI3](/auto-suite/block-explorer-and-staking-interface/nominators) 4. [**Auto SDK**](/auto-suite/auto-sdk) 5. [**Autonomys Agents (Auto Agents)**](/auto-suite/auto-agents) 6. [**Autonomys Identity (Auto ID)**](/auto-suite/auto-id) 1. [Auto Score](/auto-suite/auto-id/auto-score) 2. [Auto PKI](/auto-suite/auto-id/auto-pki) # Space Acres | CLI An overview of Autonomys' node running software ## Farmers [Farmers](/auto-suite/spaceacres-cli/farmers) can pledge SSD space to earn [$AI3 rewards](/autonomys-network/rewards-and-fees) via: * [**Space Acres**](/auto-suite/spaceacres-cli/farmers): \~10 mins to set up. Rich interface. Zero technical knowledge required. * [**Command Line Interface (CLI)**](/auto-suite/spaceacres-cli/farmers): \~10 mins to set up. Ultimate flexibility and composability for more advanced users. ## Operators [Operators](/auto-suite/spaceacres-cli/operators) can currently pledge compute to earn $AI3 rewards via: * [**Command Line Interface (CLI)**](/auto-suite/spaceacres-cli/operators): \~10 mins to set up. Ultimate flexibility and composability for more advanced users. Read our [official documentation](https://docs.autonomys.xyz/) for installation and setup instructions and further technical details. # Farmers | Store to Earn $AI3 An overview of our farming software ## Background A major barrier to mass adoption in web3 is often the technical expertise required to participate in decentralized networks. Running blockchain node software from a command line interface (CLI) on specialized hardware is particularly difficult for the average user. This accessibility hurdle threatens to limit some of the greatest benefits of the web3 ecosystem to a small number of highly technical individuals and enterprises. ## Space Acres **Space Acres**, our [farmer node](/autonomys-network/nodes) running software, abstracts away these complexities through an intuitive graphical user interface (GUI) that allows anyone with a consumer-level computer to pledge SSD space to the Autonomys Network in exchange for [$AI3 rewards](/autonomys-network/rewards-and-fees), while Space Acres seamlessly handles the backend [consensus](/autonomys-network/consensus) and [DSN](/autonomys-network/distributed-storage-network) operations. This incentivization model scales rewards to contributors based on their amount of pledged storage, fostering a scalable decentralized data storage solution. Space Acres provides several key features that simplify the farming process: * **Configuration**: Users can easily configure their reward address, node location, multiple farms, and P2P ports through the user-friendly interface. * **Node Sync**: The node synchronization process is displayed with progress, speed, and estimated time remaining (ETA), keeping users informed about the status. * **Plotting and Farming**: Space Acres displays plotting/farming piece cache progress and replotting progress, and calculates the speed, giving users visibility into their farming operations. * **Auditing and Proving**: Performance indicators for farmer auditing and proving are provided, allowing users to monitor their contribution to the network. * **Sector State Visualization**: The state of farmers' sectors is visually represented, providing a clear overview of their storage contribution. To learn more and **install Space Acres**, visit our [farming documentation](http://docs.autonomys.xyz/farming/space-acres/install/). ## Command Line Interface (CLI) To start farming via CLI, visit our [farming documentation](https://docs.autonomys.xyz/farming/cli/install). # Operators | Compute to Earn $AI3 An overview of running an operator node ## Running an operator node Anyone with a sufficiently powerful computer can pledge compute to the Autonomys Network in exchange for [$AI3 transaction fees](/autonomys-network/rewards-and-fees). Operator nodes validate and execute transactions on [decoupled execution (DecEx) domains](/autonomys-network/decoupled-execution) sharing the security of the [farmer](/auto-suite/spaceacres-cli/farmers)-maintained consensus chain. Operators (and [nominators](/auto-suite/block-explorer-and-staking-interface/nominators)) [stake](/autonomys-network/decoupled-execution/staking) $AI3 to their node which is slashed if they are dishonest, providing crypto-economic security by disincentivizing bad actors. Fees incentivize operators to maintain high standards of reliability and efficiency in transaction processing as part of a self-sustaining ecosystem. ## Command Line Interface (CLI) To check the hardware requirements for running an operator node, and to get started via CLI, visit our [operator documentation](http://docs.autonomys.xyz/staking/operator/register). # Block Explorer and Staking Interface An overview of Autonomys' staking and block exploring web app ## Nominators [Nominators](/auto-suite/block-explorer-and-staking-interface/nominators) can [stake](/autonomys-network/decoupled-execution/staking) $AI3 to earn a share of an [operator](/auto-suite/spaceacres-cli/operators)'s [$AI3 transaction fees](/autonomys-network/rewards-and-fees), and explore blocks via: * [PolkadotJS](https://polkadot.js.org/apps/#/explorer): Web application with a rich interface. * [Auto Portral (Under Active Development)](https://github.com/autonomys/auto-portal): Staking interface with user-friendly UI. Minor web3 wallet skills required. Read our [official documentation](http://docs.autonomys.xyz/staking/stake) for guidance and technical details on nomination. # Nominators | Stake to Earn $AI3 An overview of staking $AI3 to operators Any $AI3 token holder can nominate ([stake](/autonomys-network/decoupled-execution/staking) $AI3) to their preferred [operator](/auto-suite/spaceacres-cli/operators)'s nomination pool in exchange for a share of the [transaction fees](/autonomys-network/rewards-and-fees) that operator earns. Nominators increase the operator's total stake and therefore their chance of producing a [transaction bundle](/autonomys-network/decoupled-execution/domains) and earning fees, but also share in any slashing risks. This creates a symbiotic relationship between operators and nominators that incentivizes optimal performance and enhances network security and efficiency. ## Auto Portal To begin staking $AI3 to operators, visit the [Auto Portal](https://auto-portal-web.vercel.app/dashboard) (under development, expect bugs). The standard [polkadot.{js}](https://polkadot.js.org/apps/#/extrinsics) interface is also available for those who prefer more options. To learn more, read our [nominator documentation](http://docs.autonomys.xyz/staking/stake/). # Auto SDK An overview of Autonomys' software development kit The [**Auto SDK**](http://develop.autonomys.xyz/sdk) is a powerful toolkit of JavaScript/TypeScript packages for developers to seamlessly integrate with the Autonomys Network. It provides simple APIs for interacting with the [*consensus*](/autonomys-network/consensus) layer, utilizing [*data storage*](/autonomys-network/distributed-storage-network), managing [*decentralized identities*](/auto-suite/auto-id), and (soon) handling [*$AI3 payments*](/autonomys-network/rewards-and-fees), in addition to general-purpose functions essential for building decentralized applications (dApps)—all in JavaScript and TypeScript—abstracting away the complexities of blockchain and smart contracts. ## Key features * **Modular Architecture**: Use only the packages you need. * **Easy to Use**: Simplifies blockchain operations with high-level functions. * **Flexible**: Suitable for both beginners and experienced blockchain developers. * **Open-source**: Built by and for the community. ## Why the Auto SDK? * **Simplify Development**: Focus on your application’s logic rather than blockchain intricacies. * **Accelerate Time-to-Market**: Reduce development time with ready-to-use functions. * **Ensure Compatibility**: Stay up-to-date with the latest Autonomys blockchain protocols. * **Enhance Security**: Utilize well-tested code for critical operations like identity management. To start building and deploying on the Autonomys Network, and to learn more about the Auto SDK, Auto EVM and Autonomys Agents Framework, visit the [Autonomys Developer Hub](https://develop.autonomys.xyz/) and [Auto SDK GitHub repository](http://github.com/autonomys/auto-sdk). # Auto Drive An overview of Autonomys' interface for accessing the DSN **Auto Drive** is a decentralized content-addressed storage solution built on the Autonomys Network. Auto Drive transforms the underlying blockspace that forms the foundation of Autonomys’ distributed storage network (DSN) into a secure, easy-to-use, interoperable data storage tool with a user experience akin to Web2 cloud platforms. ## Key features * **True On-chain Storage**: Unlike other "decentralized" storage solutions that often simply distribute data across servers, Auto Drive provides access to genuine on-chain blockspace. This means your data inherits the same permanence, security, and decentralization guarantees as the Autonomys Network itself. * **User-Friendly Dashboard**: Auto Drive offers an intuitive web interface at [ai3.storage](https://ai3.storage/) that makes storing and accessing blockspace as simple as using a traditional cloud storage service. Users can drag and drop files, create directories, and manage their stored data with ease. * **End-to-End Encryption Options**: Security is paramount in the decentralized ecosystem. Auto Drive provides optional end-to-end encryption, giving flexibility that puts you in complete control of your data security while maintaining the benefits of on-chain blockspace. * **Developer-Friendly SDK and API**: For developers looking to integrate blockspace into their applications, Auto Drive offers: * A comprehensive TypeScript/JavaScript SDK via [@autonomys/auto-drive](https://github.com/autonomys/auto-sdk/tree/main/packages/auto-drive) * A RESTful API with complete documentation * Familiar interfaces that make integration straightforward * **Scalable Data Structure:** Auto Drive utilizes the Auto-DAG (Directed Acyclic Graph) data structure, which breaks down larger files into manageable chunks that fit within the network's blockspace. This approach ensures: * Data integrity through cryptographic verification * Efficient storage and retrieval * The ability to store files of any size within the available blockspace ## **Why Auto Drive?** Today's Web3 ecosystem faces a significant contradiction: while blockchain transactions themselves are immutable and decentralized, the actual data referenced by those transactions is often stored on centralized or temporary infrastructure, creating critical reliability issues. This is because traditional blockchain networks and storage solutions treat data storage as a separate service—either on-chain at enormous cost or off-chain with compromised security. In the Autonomys Network, storage is an intrinsic byproduct of the network's consensus mechanism—Proof-of-Archival-Storage (PoAS)—which naturally generates vast amounts of blockspace. Auto Drive makes this blockspace accessible to developers and users. Data stored via Auto Drive is secured by the network’s consensus and permanently stored in the same blockspace that maintains the Autonomys Network’s own history and state. ## **Getting Started with Auto Drive** Ready to experience truly on-chain blockspace at practical prices? Here's how to get started: 1. **Auto Drive Dashboard**: Visit [ai3.storage](https://ai3.storage/) and sign in with your preferred authentication method 2. **Developer Integration**: Install the SDK with `npm install @autonomys/auto-drive` or `yarn add @autonomys/auto-drive` 3. **API Access**: Create API keys on the Auto Drive Dashboard to access the full functionality programmatically ## Resources * [Autonomys Developer Hub (Auto Drive)](http://develop.autonomys.xyz/sdk/auto-drive) — Get started with Auto Drive * [Auto Drive Dashboard](https://ai3.storage/) — Web app for uploading, downloading and sharing files & folders, and creating API keys for the Auto SDK * [Auto Drive Gateway](https://gateway.autonomys.xyz/) — Unified interface for accessing files & folders stored on Autonomys' mainnet and Taurus testnet * [Auto Drive API docs](https://mainnet.auto-drive.autonomys.xyz/api/docs) — Available function signatures * [Auto SDK (Auto Drive)](https://github.com/autonomys/auto-sdk/tree/main/packages/auto-drive) * [Auto Drive Repository](https://github.com/autonomys/auto-drive) # Auto Drive File Encryption Specification ### Introduction The Autonomys Decentralized Storage Network (DSN) implements client-side encryption for user files. When you upload a file to the Autonomys network, it's encrypted before being transmitted to the network. This means that the decentralized network stores encrypted versions of your files, and only someone with the correct password can decrypt and access the original content. ### Client-Side Encryption Process Files are encrypted entirely on the client side before any data is sent to the network. The encryption happens on your device using your password, and the resulting encrypted data is what gets transmitted to and stored by the DSN. The encryption process uses established cryptographic algorithms and follows a chunked approach where files are broken into pieces and each piece is encrypted separately. This allows for efficient processing of files of any size and enables streaming operations. The beauty of this approach is that it eliminates trust requirements. You don't need to trust the network operators, storage providers, or any other party involved in the decentralized network. Even if someone gains access to the stored data, they would only see encrypted information that appears completely random without your password. ### The Encryption Algorithm: AES-256-GCM Autonomys DSN uses AES-256-GCM, which is considered the [gold standard](https://en.wikipedia.org/wiki/Galois/Counter_Mode#Security) for file encryption. AES stands for Advanced Encryption Standard, and the "256" refers to the 256-bit key length, which provides exceptional security. To put this in perspective, even with the most powerful computers available today, it would take longer than the age of the universe to break this encryption through brute force attacks. The "GCM" part stands for [Galois/Counter Mode](https://csrc.nist.rip/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-spec.pdf), which is a special way of applying the AES encryption that provides two important benefits. First, it encrypts your data so that it becomes unreadable to anyone without the key. Second, it creates an authentication tag that acts like a tamper-evident seal - if anyone tries to modify your encrypted file, even by a single bit, the decryption process will immediately detect this and refuse to proceed. This dual protection ensures both confidentiality (your data stays private) and integrity (your data stays unmodified). The same encryption standard is used by governments and major corporations worldwide to protect their most sensitive information. ### Password-Based Key Generation Since users typically work with passwords rather than cryptographic keys, the system uses PBKDF2 (Password-Based Key Derivation Function 2) to convert passwords into the encryption keys needed for AES-256. The key derivation process works as follows: your password is combined with a randomly generated 32-byte value called a "salt." This combination is then processed through the SHA-256 hash function exactly 100,000 times. This repetitive process serves an important security purpose - it makes password-based attacks computationally expensive and time-consuming. Each file gets its own unique 32-byte salt, which is generated using cryptographically secure random number generation. This salt is stored with your encrypted file because it's needed for decryption, but it doesn't compromise security - its purpose is to ensure that even if two people use the same password, their encryption keys will be completely different. ### How Files Are Encrypted The encryption process breaks files into chunks of 1 megabyte each and encrypts each chunk separately. This chunked approach allows for efficient processing of large files and enables streaming operations where encryption can begin before the entire file is available. For each chunk of data, the system generates a unique 16-byte initialization vector (IV) using cryptographically secure random number generation. This IV ensures that identical chunks of data will produce different encrypted outputs, which is important for security. The encryption process for each chunk combines the original data with its unique IV and processes it through the AES-256-GCM algorithm using the key derived from your password. The result is an encrypted chunk that contains both the encrypted data and an authentication tag generated by the GCM mode. ### Privacy in a Decentralized Environment One of the most compelling aspects of Autonomys DSN's encryption approach is how it addresses the unique privacy challenges that arise in decentralized storage networks. Unlike traditional cloud storage where you must trust a single company with your data, decentralized networks involve multiple independent parties who participate in storing and serving your files. The client-side encryption creates a privacy layer that works regardless of how many parties are involved in the storage process. When your encrypted file enters the DSN, it gets processed through the network's multi-layered architecture. Nodes in the content delivery network layer, farmers caching pieces in the distributed hash table layer, and participants in the archival storage layer all handle only encrypted data. From their perspective, your file appears as cryptographically random data - they cannot determine what type of content you're storing, how large your original files are, or any meaningful information about your data. This privacy protection works at multiple levels of the network interaction. When farmers receive pieces of your encrypted file for storage in their plots, they're working with data that has already been encrypted on your device and potentially further processed by the DSN's encoding schemes. The encryption ensures that even if someone gained access to multiple storage locations across the network, they would only find encrypted fragments that provide no insight into your original content. The decentralized nature of the network actually enhances privacy in some ways compared to centralized systems. There's no single point where your complete file exists in unencrypted form outside of your own device. The distribution across multiple independent storage providers means that no single party has a complete view of your storage activity, and the encryption ensures that partial views remain meaningless. This approach also provides privacy protection that persists over time. As the network evolves, as storage providers join and leave, and as the DSN's architecture develops, your files remain protected by the same client-side encryption that was applied when you first stored them. The privacy guarantees don't depend on the ongoing security practices of any particular storage provider or network operator. ### Performance and Efficiency Considerations The encryption system is designed to be efficient while maintaining strong security. The choice of 1 MB chunks strikes a balance between memory usage and computational efficiency. This chunking allows files to be processed in a streaming fashion, meaning you don't need to load entire large files into memory at once, and encryption can begin before the entire file is available. AES-256-GCM is specifically chosen for its performance characteristics. Modern processors often include hardware acceleration for AES encryption, making the process very fast. The GCM mode is also optimized for performance while providing the authentication features needed for secure storage. The computational overhead of the encryption process is minimal for the actual encryption and decryption operations. The most time-consuming part is the initial key derivation from your password, which is intentionally slow for security reasons. However, this only happens once per file, and the derived key is then used efficiently for all chunks of that file. # Autonomys Agents (Auto Agents) An overview of the Autonomys Agents Framework ## Background On-chain AI agents—with their capabilities for natural language processing (NLP), autonomous transaction execution, and interaction with external APIs via distributed compute—are uniquely able to abstract away the complexities of blockchain that have long stood in the way of web3 accessibility. However, their explosive growth has exposed a critical vulnerability in their architecture: the lack of permanent, verifiable records of their interactions and decision-making processes. While the market has seen solutions ranging from simple chatbots to sophisticated analysis tools, these agents typically operate on centralized storage systems, making them vulnerable to data loss, manipulation, and censorship. Incidents of high-profile AI agents being shut down due to unverifiable decision-making processes highlight the urgent need for a more robust solution.
## Autonomys Agents Framework The [**Autonomys Agents** (**Auto Agents**) **Framework**](https://github.com/autonomys/autonomys-agents/tree/main) enables developers to build truly autonomous on-chain AI agents capable of dynamic functionality, verifiable interaction, and permanent, censorship-resistant memory through the Autonomys Network. By permanently archiving each interaction, decision, and reasoning process on-chain, Auto Agents ensure that every aspect of their operation is accessible, auditable, and cryptographically verified. This transparent queryable memory allows anyone to study, analyze and learn from Auto Agents' behavior—both expected and unexpected. The Auto Agents Framework is still in the early stages of development. It currently uses the [Auto SDK](/auto-suite/auto-sdk), including the Auto Drive API, to interact with the [PoAS consensus](/autonomys-network/consensus) chain and interface with the [distributed storage network (DSN)](/autonomys-network/distributed-storage-network). Autonomys Labs is rapidly improving the framework and adding workflows and features that will expand Auto Agents' capabilities. Any feedback and contributions are appreciated. {% embed url="" %} Getting started with the Autonomys Agents Framework {% endembed %} ## Key features * 🤖 Autonomous social media engagement * 🧠 Permanent agent memory storage * 🔄 Built-in orchestration system * 🐦 X/Twitter integration (with more platforms planned) * 🎭 Customizable agent personalities * 🛠️ Extensible tool system * ✨ Multi-model support (Anthropic, OpenAI, Llama, DeepSeek) To start building and deploying an Auto Agent, and to learn more about the Autonomys Agents Framework, visit the [Autonomys Developer Hub](http://develop.autonomys.xyz/auto_agents_framework/introduction) and [Autonomys Agents Framework GitHub repository](https://github.com/autonomys/autonomys-agents). ## Why the Auto Agents Framework? The Auto Agent Framework enables three critical capabilities previously unattainable for AI agents: 1. #### True Data Permanence * Immutable storage of all agent interactions * Cryptographic verification of data integrity * Distributed redundancy prevents data loss 2. #### Complete Operational Transparency * Comprehensive audit trails of decision-making * Real-time verification of agent actions * Public accessibility of agent memory 3. #### Genuine Autonomous Operation * Independent decision-making capabilities * Self-contained operational logic * Resistance to centralized control ## Example: [Argu-mint](https://www.autonomys.xyz/post/meet-argu-mint-the-first-auto-agent-immortalizing-debate-on-chain) ([@0xargumint](http://x.com/0xargumint)): The First Truly On-Chain Agent {% embed url="" %} [Explainer Article](https://www.autonomys.xyz/post/autonomous-agents-on-the-autonomys-network-argu-mint-demo) {% endembed %} [Argu-mint](https://www.autonomys.xyz/post/meet-argu-mint-the-first-auto-agent-immortalizing-debate-on-chain) serves as a powerful demonstration of the Autonomys Agent Framework's capabilities. As the first AI agent to store its entire social interaction history permanently on-chain, it showcases several key innovations in its memory architecture, including: * Chronological chaining of all interactions * Cryptographic linking between memory states * Query-optimized storage structure * Real-time reasoning verification ### Workflow 1. Monitors X for relevant discussions 2. Analyzes context and potential engagement value 3. Generates and verifies responses 4. Archives entire decision process on-chain 5. Maintains permanent, queryable record at [0xargumint.ai](https://0xargumint.ai/) ## Real-world applications The verifiable, permanent on-chain memory provided by the Autonomys Agent Framework addresses critical accountability challenges for AI agents, while its versatility enables a variety of cross-sector applications: * **Financial Services** * Market analysis agents with verifiable decision trails * Risk assessment systems with permanent audit records * Trading strategy verification and historical analysis * Resolving indeterminate prediction market results with transparent, on-chain reasoning * **Social Media and Content Management** * Content moderation with transparent reasoning * Engagement analysis with permanent records * Trend prediction with verifiable methodology * **Research and Development** * Experimental data preservation * Algorithm verification and validation * Historical analysis with complete audit trails ## Architecture The Auto Agent Framework ingests inputs from various sources, processes them through a sequence of decision-making and planning steps, and executes tasks, while storing all relevant data in its permanent memory on the Autonomys Network's DSN. Each step relies on specialized cognitive 'engines' that work in synergy: * **Think**: Interprets and contextualizes new inputs. * **Plan**: Devises a strategy or sequence of steps to address the input. * **Execute**: Carries out the plan by calling the relevant tools or sub-workflows. These stages are orchestrated by a master workflow which coordinates domain-specific workflows when specialized knowledge or actions are required. Each domain workflow can have its own local or dedicated tools for narrower tasks. Memory is designed to be modular: workflows can maintain their own domain-specific memory while a higher-level orchestration retains general system memory. Input sources currently include communication platforms, scheduled research, and the command line interface (CLI). A tool refers to any functional endpoint or code module that executes a distinct operation. Examples include: APIs (internal or external); blockchain interactions (any form of transaction); database operations (e.g. queries, insertions, analytics); local scripts and plugins (e.g. data transformation or system tasks); LLM prompts (secondary or specialized prompts); and custom libraries and modules (e.g. for text or vision processing). Tools can be grouped into two categories: 1. **Global (Agent-Wide) Tools** * Accessible by all domains and the master workflow. * Typically includes universal utility functions or cross-domain services. 2. **Local (Domain-Specific) Tools** * Only used within a particular domain workflow. * Tailored to domain needs (e.g. a financial data aggregator). ## Workflow ### Thinking/decision engine The thinking/decision engine is where raw inputs from any source are first evaluated using LLM reasoning: 1. **Interpretation and Contextualization**: The engine examines incoming information in the context of the agent’s overarching goals. It considers questions such as “Why did I receive this input?” and “Does it align with current objectives or require new ones?” 2. **Decision Logic**: Once the input is interpreted, the engine decides whether to ignore it, store it for later, or escalate it to the planning engine. This involves: * Checking existing memory for related data or previous occurrences. * Evaluating priority levels—some inputs might trigger immediate action while others can wait. * Determining if new knowledge or capabilities are required. If the agent has a specific persona, the thinking engine will factor that into how it frames the next step. For instance, a risk-averse persona might approach tasks differently than a proactive one. ### Planning engine If the thinking/decision engine escalates an input, the planning engine is responsible for designing a plan of action: 1. **Goal Decomposition**: The engine outlines the core objective, breaking it down into discrete steps or sub-goals. For example, “Gather data”, “Analyze for insights”, and “Report results to stakeholders”. 2. **Tool Selection**: Before finalizing a plan, the engine asks, “What tools do I have available to accomplish these steps?” 3. **Knowledge Requirements**: The engine identifies what it needs to know (e.g. domain-specific facts or user preferences). If the knowledge is missing, it might initiate a research sub-task or consult domain-specific memory. 4. **Contingency Planning**: If the agent’s capabilities are incomplete or uncertain, the plan can include fallback or error-handling steps. This structure makes it possible to add or remove steps without rebuilding the entire system from scratch. ### Execution engine Once a plan is created, it flows into the execution engine for fulfillment. This engine’s responsibilities include: 1. **Action Orchestration**: Each step from the plan triggers the appropriate tool or sub-workflow. If an API call is needed, the engine handles authentication, sends requests, and processes responses. 2. **Progress Monitoring**: If any step fails or returns unexpected results, the engine can either retry, skip, or pass the failure back to the thinking/decision engine for a revised plan. 3. **Asynchronous and Event-Driven Tasks**: The engine can be designed to handle asynchronous events, waiting for external triggers (like data arrival) or scheduling re-checks for timed events. Throughout execution, the engine captures intermediate outcomes in a designated memory store, ensuring that subsequent steps have the context needed to continue. ### Master workflow (top-level orchestration) The master workflow is the overarching LLM-driven process that: 1. **Receives Inputs**: Collects incoming requests or triggers from various communication channels, CLIs, or scheduled research tasks. 2. **Thinks**: Invokes the thinking/decision engine to determine the nature of the request and whether action is needed. 3. **Plans**: If action is needed, the planning engine breaks down the goal into sub-tasks and identifies the applicable tools/workflows that are needed to accomplish the tasks. 4. **Executes**: Once the plan is set, the workflow executes each task. If any step is domain-specific, it delegates to the corresponding domain workflow (described below). This top-level orchestration ensures a consistent, high-level approach to every request while remaining flexible enough to delegate specialized tasks. ### Domain-specific workflows (sub-flows) For more complex or specialized tasks, the master workflow invokes domain-specific workflows. Each domain (e.g. social media, marketing, financial action) can encapsulate its own: * **Thinking Logic**: Domain-specific instructions or rules that help contextualize steps within that field. * **Planning Steps**: Sub-tasks unique to the domain, such as financial analysis or retrieving specific data sets. * **Local Tools**: APIs, scripts, or services relevant only to that domain. As each domain workflow is self-contained, you can add or remove domains without disrupting the master flow, or evolve a domain workflow independently (e.g. add advanced analytics for finance) while keeping the global agent architecture stable. ### Decision-making on tool usage During the 'thinking' and 'planning' stages, the agent decides which tool or domain workflow to call. This decision is driven by: * **Context**: What is the current goal or task? Which domain or tool can fulfill this task? * **Available Capabilities**: Does the agent have the right set of tools to address the problem? ### Memory management A permanent memory enables the agent to maintain continuity, learn from past actions, and handle specialized tasks. Our design treats memory as modular, allowing different workflows or domains to manage their own data, while the top-level orchestration layer maintains broader system knowledge: * **Local (Short-Term) Memory** * **Purpose**: Captures ephemeral data during a single execution cycle or workflow. * **Blockchain Integration**: During task execution, this memory remains off-chain (typically in RAM for efficiency). When a workflow completes, any data deemed relevant for historical or analytical purposes can be selectively committed to the blockchain with a new CID. Most local memory is not stored permanently unless needed for future reference. * **Domain-Specific Memory** * **Purpose**: Maintains specialized knowledge relevant to a particular domain (e.g. financial data, product info, engineering logs). * **Blockchain Integration**: * **On-Chain References**: Each domain can store snapshots or curated updates as on-chain objects with unique CIDs. These on-chain references use the linked-list approach (CID + previous CID) to preserve the chronological chain of updates. This ensures a tamper-proof record of domain-specific facts or logs that the agent can later reference. * **Off-Chain Index + On-Chain Anchors**: If some domain data is too large or too frequently updated to store directly on-chain, an off-chain index (e.g. a vector database) can be used and anchor references (hashes or metadata) can be periodically added to the blockchain. The agent thus benefits from both efficient retrieval (off-chain) and cryptographic integrity (on-chain). * **General (Permanent) Memory** * **Purpose**: Long-term, system-wide store of the agent’s historical decisions, high-level outcomes, or “chain of thought”. * **Blockchain Integration**: * **Singly Linked List of CIDs**: Each time the agent finalizes a significant thought or 'checkpoint', it commits an object to the blockchain with a CID pointing to the previous CID. This forms an immutable timeline (or chain) of the agent’s evolution—helpful for auditing, debugging, or advanced analytics. * **Proof-of-Archival-Storage**: As the Autonomys Network is built on a PoAS consensus model, each piece of agent data is replicated widely. This architecture ensures data longevity and censorship resistance, as no single node can quietly remove or alter records once they have been included in the chain. * **Efficient Retrieval by CID**: Any engine—thinking, planning, or execution—can retrieve past states or decisions using the object’s CID. This retrieval mechanism also supports partial or incremental lookups, meaning the agent can reconstruct previous reasoning without scanning the entire chain. These memory layers work in tandem. When a new input arrives, the thinking/decision engine references general memory to check if a similar event has happened before, while the planning engine may query domain-specific memory for relevant facts. Each level may choose a mix of permanent blockchain storage and local data storage and retrieval systems, such as vector databases. Over time, these memory modules can grow and evolve, providing rich context for more advanced or creative tasks. ## Summary The Auto Agents Framework provides a robust, modular architecture and workflow with specialized engines that handle thinking, planning and execution, supported by a tiered memory model that maintains both short-term, domain-specific, and general data. As Auto Agents' capabilities enhance, each engine and memory store will evolve to better handle complex tasks, making the system increasingly proactive, adaptive and valuable. ## Future development roadmap Autonomys' strategic roadmap currently focuses on three key areas: 1. **Technical Advancement** * Decentralized inference capabilities * Enhanced identity frameworks * Advanced reasoning systems * Coordinated agent memory/communication protocols for collective intelligence 2. **Infrastructure Enhancement** * Increased storage capacity * Improved network performance * Enhanced scalability * Advanced security features 3. **Ecosystem Growth** * Extended SDK capabilities * Additional integration options * Advanced testing frameworks * Community development tools # Autonomys Identity (Auto ID) An overview of Autonomys' decentralized identity framework **Autonomys Identity (Auto ID)** is our universal, self-sovereign [digital identity](https://academy.autonomys.xyz/auto-suite/pages/ShdMNm1Ijwi1OjeQOGPc#c.-digital-identity) framework for [the Age of Autonomy](/autonomys-vision/intro-to-ai3), and a key building block for future [AI agent-augmented DAO governance](https://academy.autonomys.xyz/auto-suite/pages/ShdMNm1Ijwi1OjeQOGPc#j.-open-collective-intelligence-and-the-global-dao-mesh). Auto IDs allow anyone to verify the identity of humans and agents and the [provenance of the content](https://academy.autonomys.xyz/auto-suite/pages/ShdMNm1Ijwi1OjeQOGPc#b.-content-provenance-and-data-sovereignty) they create, fostering online trust and transparency in an increasingly AI-integrated world. Based on the [Auto PKI](/auto-suite/auto-id/auto-pki), a decentralized public key infrastructure, Auto IDs can be self-issued by any natural entity (humans and organizations) and externally issued to any digital entity ([agents](/auto-suite/auto-agents), models, software, etc.) by any natural entity. Multiple entities can also jointly issue composite Auto IDs. Digital entities can be delegated authority via Auto ID, authorizing them to act on the issuer's behalf. Each Auto ID has a unique public identifier (similar to a username) and cryptographic key pair (similar to a password). Auto IDs are registered on the public Auto Registry [domain](/autonomys-network/decoupled-execution/domains) on the Autonomys Network and certified by the issuer's private key. Users able to demonstrate a valid [proof-of-personhood](https://academy.autonomys.xyz/auto-suite/pages/ShdMNm1Ijwi1OjeQOGPc#d.-proof-of-personhood) (an Auto ID with a high [Auto Score](/auto-suite/auto-id/auto-score)) can register their Auto ID for free. ## Key features * **Verifiable**: Anyone can verify the ownership provenance of an Auto ID and the legitimacy of its granted claims through the use of digital signatures and the relevant public keys (if the Auto ID is registered in a public database). * **Portable**: Auto IDs are self-contained, and thus not inherently tied to any one provider or registry, allowing for easy movement across platforms. * **Interoperable**: Auto IDs are based on a common, open standard and are compatible with [X.509 Public Key Infrastructure (PKI)](/additional-learning/identity-security/public-key-infrastructure) certificates and the [Open ID Connect (OIDC)](/additional-learning/identity-security/oauth-and-oidc) account model. * **Secure**: Any two entities with Auto IDs can establish an authenticated and encrypted communication channel over a public network using mutual Transport Layer Security ([mTLS](https://www.cloudflare.com/en-gb/learning/access-management/what-is-mutual-tls/)), regardless of implementation, provider, or platform. * **Universal**: Auto IDs can be linked to any number of identity claims or verifiable credentials, enabling them to act as universal digital passports. * **Accountable**: All entities with Auto IDs can be held accountable for their actions via non-repudiable digital signatures stored on Autonomys' [DSN](/autonomys-network/distributed-storage-network). * **Revocable**: Auto IDs can be revoked at any time in a manner that is verifiable by anyone (if the issuer has registered their Auto ID in a public database). * **Recoverable**: Entities can be issued a new Auto ID by their issuer (if not self-issued) or by the database (if self-issued and registered) if they lose access to its private key. ## Developers The Auto SDK contains a simple account model for issuing digital identities to autonomous entities; an authentication system that allows entities to prove they hold a given identity; and an authorization framework for delegating identity and access claims between entities: * **Auto ID** provides ***identification*** for autonomous entities using a simple, extensible, and [X.509](/auto-suite/auto-id/auto-score)-compatible standard for binding self-selected public identifiers to self-generated public keys through digital signatures, across an array of conceivable issuance and registration models. * **Auto AuthN** provides ***authentication*** for autonomous entities by using Auto ID certificates over any Transport Layer Security (TLS) channel, where each entity validates certificates based on their chosen trust model and its associated Public Key Infrastructure (PKI). * **Auto AuthZ** provides ***authorization*** for autonomous entities through compatibility with the Open Authorization (OAuth) and Open ID Connect (OIDC) protocols, allowing identity and access claims to be delegated and bound to an Auto ID by using nested digital signatures. In summary, the Auto SDK provides developers with a common standard for identifying, authenticating, and authorizing natural and digital entities in a way that is backwards-compatible with widely adopted standards such as X.509 PKI certificates, communication over TLS, and the OAuth and OIDC protocols. To start building Auto ID-powered dApps and agents with the [Auto SDK](/auto-suite/auto-sdk), visit the [Autonomys Developer Hub](https://develop.autonomys.xyz) and [Auto SDK GitHub repository](http://github.com/autonomys/auto-sdk). ## Example: Demonstrating Provenance for AI-Generated Content Alice uses an instance of an open-source AI model to help write content and generate images for her social media posts. She wants to show that her content is AI-generated. By linking her Auto ID to her user-specific instance of the AI model, she can demonstrate that the content she published was produced with that specific AI model at a specific time by digitally signing each piece of content and including a short proof-of-provenance alongside her post, meaning anyone can verify it. # Auto Score An overview of Autonomys' proof-of-personhood protocol ## Background Current solutions to proof-of-personhood (PoP) suffer from a trade-off between security and user-friendliness. To be scalable, efficient, and secure, a system should be open-source from top to bottom, have no biometrics collection, and have a mechanism for claiming and reissuing identities. ## Auto Score **Auto Score** is the sybil-resistant on-chain [proof-of-personhood](https://academy.autonomys.xyz/auto-suite/auto-id/pages/ShdMNm1Ijwi1OjeQOGPc#d.-proof-of-personhood) framework utilized by Auto ID. An Auto Score is a measure of the probability of an entity's humanity calculated as a weighted aggregate of an Auto ID's verifiable online identities and credentials. Auto IDs can include internal claims (attested by the issuer) and be linked to external claims (attested by anyone), such as OIDC providers (like Google and Apple), government registries or other PoP protocols (including [World ID](https://whitepaper.world.org/#world-id), which leverages biometric scanning to register unique human identities via [the Orb](https://whitepaper.world.org/#the-orb)). Verifiable claims linking an Auto ID to a wide range of services contributes to a high overall Auto Score, as well allowing users to construct a profile that offers different levels of "proof" of their personhood. Solutions requiring some probability of humanity can then set a minimum Auto Score to permit interaction. Applications can also require specific identity claims be linked to an Auto ID for use. ## Example: Proving your Humanity Online Alice wants to create an account on a new platform which uses captchas to prevent bots. If the platform integrates Auto ID sign-in, Alice can sign up with a single click using her Auto ID, as she has linked several existing verifiable online identities, including accounts for Google, Apple and X, that can attest she has a verified email and phone number. If an Auto ID with a human-level Auto Score is required to create a new account, the cost of sybil attacks is significantly raised, as a bad actor would have to generate or purchase multiple verified accounts across several reputable providers (to obtain a human-level Auto Score), as opposed to simply solving a captcha, before being able to sign up. # Auto PKI An overview of our framework for creating custom Auto ID registries **Auto PKI** is a framework for creating and deploying unique consortium-based instances of the Auto ID registry for industry or application-specific use cases. Consortium-based identity systems are designed to facilitate secure and trusted digital interactions between a group of organizations or entities within a specific industry or domain. These systems establish a shared framework for managing digital identities, enabling participating members to authenticate and authorize individuals or entities within the consortium. Examples of consortium-based identity systems include the banking industry's efforts to establish a shared know-your-customer (KYC) platform, and the shipping industry's initiatives to create a unified system for verifying the identities of vessels and their crew members. In a consortium-based identity system built using Auto PKI, consortium members agree on policies and standards to govern the issuance, management and verification of the custom Auto IDs within their ecosystem, establishing a trusted environment where identities are recognized and accepted across the consortium. # AI & Agentics AI Changes Everything For an increasing number of individuals, the realization that artificial intelligence (AI) is reshaping our world grows more evident daily, at a pace surpassing both laypeople's and experts' expectations. Discussions on Artificial General Intelligence (AGI) – AI with human-equivalent capabilities – have shifted from whether it will occur to when. Some argue it might already exist within research laboratories, yet remains undisclosed. The of Artificial Super Intelligence (ASI) can swiftly follow: an evolution that represents a shift from machines that can perform any intellectual task that a human being can (Artificial General Intelligence - AGI,) to machines that surpass the cognitive performance of humans in virtually all domains of interest (Artificial Super Intelligence - ASI) seems inevitable, particularly considering the prospects of recursive self-improvement and intelligence explosions.
A graph from a presentation by NVIDIA's Head of Research – representing one of the world's highest-valued companies – illustrates an impending surge in technological intelligence, likened to the sharp upturn of a hockey stick, signaling an unparalleled era of transformation set to unfold at unprecedented speed. Yet, this future brings uncertainties, particularly in managing negative repercussions, trust issues, and the potential for increased centralization. The challenge of aligning AI's goals with human values persists, presenting a significant dilemma amidst anticipated changes. Despite abundant theories and conjecture, the future remains uncertain, highlighting a unique, simultaneously exhilarating and daunting period in our history. At this critical juncture, the future of AI is not predetermined, offering multiple potential paths shaped by our influence. In summary, we stand at a pivotal moment, capable of steering the future direction of AI, amidst a landscape filled with both promise and ambiguity. # Current State of AI ## **An Evolutionary Journey of “I” in AI** As a field of study, the goal of AI is to achieve a computational understanding of intelligent behavior and to develop artifacts, i.e., computers and computer programs, that exhibit intelligence, or in other words, to create computers that can perform tasks that were previously only possible for humans. **Here are some tasks that have been solved so well that they are no longer considered to require “intelligence** * **Speech recognition** * **Image content recognition** * **Natural language processing** * **Machine translation between languages** * **Self-driving vehicles** * **Autonomous weapons** AI is a vast and fast-evolving matter, and one way to categorize its progress is by classifying it into three main categories: Artificial Narrow Intelligence(ANI), General Intelligence(GI or AGI), and Super Intelligence(SI or ASI). ANI systems are good at specific tasks, like analyzing data, generating texts, recognizing images, and translating languages. ANI is already being used to automate tasks and provide insights in many industries. General Intelligence is achieved when AI is able to independently reason and solve problems for which it was not even originally designed or intended, in other words, at that point, AI begins to match human intelligence. Though AI systems are capable of performing many tasks that were once thought to be the exclusive domain of humans, it’s still far from achieving General Intelligence. Superintelligence would be AI that is smarter than humans in every way. It would be able to reason, be creative, and adapt to new situations. Superintelligence is still far away, but it is a goal that many AI researchers are working towards. ### **AI is continually evolving with rapid adoption** The current status of Artificial Intelligence is marked by a substantial increase in adoption among large companies. According to the latest [Artificial Intelligence Index report](https://aiindex.stanford.edu/report/), AI adoption among large companies has surged by an impressive 47% when compared to data from 2018. This surge in adoption underscores the growing recognition of AI’s potential to transform various industries and enhance business operations. Large companies are increasingly leveraging AI technologies to gain competitive advantages, streamline processes, and make data-driven decisions. ## **Overview of the Current Status of AI** * Machine Learning Advancements: AI’s backbone, machine learning, has seen significant advancements. Algorithms like deep learning and reinforcement learning have enabled AI systems to process vast amounts of data and improve their performance over time. These improvements have led to breakthroughs in image recognition, natural language processing, and autonomous vehicles. * Natural Language Processing (NLP) Milestones: NLP, a subset of AI, has achieved impressive milestones. Models like [GPT-4](https://alltechmagazine.com/openai-launches-gpt-4/) (Generative Pre-trained Transformer 4) can generate human-like text, making chatbots, content creation, and language translation more efficient and natural. * Autonomous Systems: AI-powered autonomous systems have made strides in fields like self-driving cars and drones. Companies like Tesla and Waymo are testing self-driving cars on public roads, showcasing the potential of AI to revolutionize transportation. * Healthcare Revolution: AI is playing a pivotal role in healthcare. From disease detection to drug discovery, AI algorithms are helping doctors diagnose illnesses more accurately and speeding up drug development processes. * Personalized Experiences: AI is enhancing user experiences by personalizing content and recommendations. Streaming services, social media platforms, and e-commerce sites use AI algorithms to tailor suggestions based on user’s preferences and behaviors. * Ethical and Bias Concerns: As AI becomes more prevalent, concerns about ethics and bias have come to the forefront. Ensuring that AI systems are fair, transparent, and free from discriminatory biases remains a challenge that the industry is actively addressing. * Limitations and Challenges: While AI has made significant progress, it still faces challenges. AI systems can struggle in situations they haven’t been specifically trained for and might lack common-sense reasoning abilities. Additionally, the energy consumption of training large AI models is a growing concern. * AI in Creativity: AI is even making strides in creative fields. AI-generated art, music, and literature are gaining attention, blurring the lines between human and machine creativity. * Business Integration: AI is being integrated into various industries, from finance to retail. Businesses are using AI for tasks like predictive analytics, fraud detection, and supply chain optimization. * Research and Innovation: Research in AI is ongoing, with scientists and engineers continuously pushing the boundaries of what AI can achieve. As technology evolves, new breakthroughs are expected in the near future. While there are challenges and ethical considerations, the potential for AI to reshape industries and enhance human experiences is undeniable. As technology continues to progress, we can expect [AI to play an even more significant role in shaping our future](https://alltechmagazine.com/artificial-intelligence-of-the-future-what-to-expect/). # What is an LLM An LLM, or large language model, is a type of artificial intelligence system that has been trained on vast amounts of text data to understand and generate human-like language. These models are capable of performing a wide range of natural language processing tasks, from answering questions and translating languages to writing creative fiction and even generating code. ## **How do large language models work?** A key factor in how LLMs work is the way they represent words. Earlier forms of machine learning used a numerical table to represent each word. But, this form of representation could not recognize relationships between words such as words with similar meanings. This limitation was overcome by using multi-dimensional vectors, commonly referred to as word embeddings, to represent words so that words with similar contextual meanings or other relationships are close to each other in the vector space. Using word embeddings, transformers can pre-process text as numerical representations through the encoder and understand the context of words and phrases with similar meanings as well as other relationships between words such as parts of speech. It is then possible for LLMs to apply this knowledge of the language through the decoder to produce a unique output. One of the most well-known examples of an LLM is [ChatGPT](https://arxiv.org/pdf/2005.14165.pdf) (Generative Pre-trained Transformer), developed by OpenAI. This model was trained on an incredible 175 billion [parameters](https://www.educative.io/answers/what-are-the-parameters-in-chatgpt-3), making it one of the largest and most sophisticated language models ever created. ChatGPT can engage in coherent conversations, write articles and stories, and even solve programming problems. It’s important to understand that today’s development in the field of LLMs are made possible because of an innovation known as transformers. The transformer enables a specific type of neural network architecture that has proven highly effective for natural language processing tasks. The transformer was first introduced in a 2017 paper titled "[Attention Is All You Need](https://arxiv.org/abs/1706.03762)" by researchers at Google Brain. It revolutionized the field of NLP by eschewing the sequential processing of previous models like recurrent neural networks (RNNs) in favor of a more parallelized approach using an "attention mechanism.” ### **Here's a high-level overview of how transformers work in LLMs:** * Embedding: The input text is first converted into numeric vector representations called embeddings. * Encoder: The embeddings pass through an encoder module made up of multiple transformer encoder layers. Each layer applies self-attention, allowing the model to weigh different word representations against each other when encoding meaning. * Decoder: The output embeddings from the encoder are then processed by a transformer decoder module, also applying self-attention along with encoding-decoding attention over the encoder representations. * Output: Finally, the decoder produces an output probability distribution over the vocabulary for predicting the next word token. ### **How are large language models trained?** Transformer-based neural networks are very large. These networks contain multiple nodes and layers. Each node in a layer has connections to all nodes in the subsequent layer, each of which has a weight and a bias. Weights and biases along with embeddings are known as model parameters. Large transformer-based neural networks can have billions and billions of parameters. The size of the model is generally determined by an empirical relationship between the model size, the number of parameters, and the size of the training data. Training is performed using a large corpus of high-quality data. During training, the model iteratively adjusts parameter values until the model correctly predicts the next token from the previous sequence of input tokens. It does this through self-learning techniques which teach the model to adjust parameters to maximize the likelihood of the next tokens in the training examples. ### **4 Key advantages of LLMs:** 1. Natural Language Understanding: LLMs have a deep grasp of human language, allowing them to comprehend context, nuance, and intent. 2. Versatility: These models can be adapted for a wide range of tasks, from language translation to content generation and analysis. 3. Scalability: LLMs can be fine-tuned on specific datasets, enabling them to acquire specialized knowledge in various domains. 4. Efficiency: Once trained, LLMs can generate human-like text quickly and at a fraction of the cost of human writers. ### **4 Limitations of LLMs:** 1. Bias and Inconsistency: LLMs can inherit biases present in their training data, leading to potentially harmful or inconsistent outputs. 2. Lack of Common Sense: Despite their language capabilities, LLMs can struggle with tasks that require common sense reasoning or real-world knowledge. 3. Factual Errors: LLMs can generate plausible-sounding but factually incorrect information, especially on topics outside their training data. 4. Ethical Concerns: The potential misuse of LLMs for generating misinformation, hate speech, or malicious content raises ethical concerns. Large language models are a remarkable achievement in the field of natural language processing, but they also come with their own set of challenges. As these models continue to evolve, it's crucial to address their limitations and ensure they are developed and deployed responsibly, with safeguards in place to mitigate potential risks. # Personal AI In the previous articles we briefly covered what an LLM is, how development of transformers were essential to the tools that we use today and discussed the current trend of Agentic AI which aims to use AI in a more meaningful and sometimes creative way. But there’s more to it! Imagine if the agent wasn’t only using the publicly available information about the world and it’s training dataset, but was able to know more about you, your set of rules and beliefs, your background and your opinions about anything and provide a unique answer which was aligned with your view of the world. That is exactly what Personal Agentic AI is. Here are some first attempts to popularize personal AI agents: * [Rabbit R1](https://www.rabbit.tech/keynote) compact personal AI assistant portable device * [Langchain](https://www.langchain.com/agents) is the leading tool for [building agents](https://python.langchain.com/docs/modules/agents/) using models like GPT-4 through the Open AI API. They have lots of [articles](https://blog.langchain.dev/planning-agents/) on their [blog](https://blog.langchain.dev/) and many webinars describing how this works. * OpenAI recently published [Practices for Governing Agentic AI systems](https://openai.com/research/practices-for-governing-agentic-ai-systems) to explain the dangers and risks of agents. ChatGPT is partially agentic. GPTs and Open AI [assistants](https://platform.openai.com/docs/assistants/overview) both allow for developing semi-agentic AI. * Popular movie [Her](https://en.wikipedia.org/wiki/Her_\(film\)) shows well what a personal AI agent that starts as AGI and becomes ASI would look like. * [PersonalAI](https://www.youtube.com/watch?v=SLgo4fRQjzM) which essentially creates your digital twin, with representation of your memory (Memory Stack) and your personal talking style (Personal Language Model), that chats with your friends instead of you.

Rabbit R1 - example of personal AI portable device

## **Agent Decision-Making and Planning** From managing your investments to meal planning for your family, your personal AI agent juggles a myriad of tasks and objectives. To make optimal decisions aligning with your long-term goals and priorities, it employs advanced decision-making and planning strategies. Using decision-theoretic models, your agent evaluates the potential outcomes and ripple effects of each possible course of action when arranging your day. It weighs factors like your schedule constraints, health tracking data, traffic predictions, and even your latest emotional state readings. With techniques like [Monte Carlo tree search](https://en.wikipedia.org/wiki/Monte_Carlo_tree_search), it rapidly simulates millions of branching future scenarios to plot out ideal schedules and plans. In domains lacking full predictability, like negotiating major purchases or fielding open-ended queries, your AI leverages game theory and reinforcement learning. It constructs models of the other agents' behaviors and updates its own response strategies based on their actions and your feedback, continually learning to make better decisions tailored just for you. ## **Agent Learning** What makes your personal AI agent truly remarkable is its ability to continuously learn, adapt, and grow more personalized with each interaction and new experience. It's an ever-evolving repository of your preferences, habits, and idiosyncrasies. Through supervised learning on all your past data, from emails and documents to calendar events and GPS traces, your agent builds rich predictive models of your behavior and patterns. It learns to automate routine tasks while also identifying anomalies worthy of your attention. But your AI goes beyond following rules - it observes the real-world outcomes and your feedback to refine its behavior through reinforcement learning. If you override a scheduling decision, it learns. If you express dissatisfaction with a suggestion, it course-corrects its strategy. Moreover, by processing natural conversations through unsupervised learning, your AI agent bootstraps its own conceptual understanding to provide more intelligent and nuanced responses. Over time, it develops an emergent model of you as a unique individual - your traits, idiosyncrasies, and the very essence of how you think. In essence, it becomes an extension of your own cognition and identity. # What is an AI Agent ## Agents An [**agent**](https://aima.cs.berkeley.edu/) is just something that acts (*agent* comes from the Latin *agere*, to do). Of course, all computer programs do something, but computer agents are expected to do more: operate autonomously, perceive their environment, persist over a prolonged time period, adapt to change, and create and pursue goals. A **rational agent** is one that acts so as to achieve the best outcome or, when there is uncertainty, the best expected outcome. An AI agent can be a software program, a robot, or any other system that exhibits autonomous behavior and decision-making capabilities. The 5 key characteristics of an AI agent can include: 1. Perception: The ability to perceive and interpret the external environment through sensors, such as cameras, microphones, or other types of input devices. 2. Reasoning: The ability to process the perceived information, reason about it, and make decisions based on that reasoning. 3. Action: The ability to take actions or perform tasks that affect the environment through actuators, such as motors, speakers, or other output devices. 4. Goals: AI agents are designed to pursue specific goals or objectives, which guide their decision-making and behavior. 5. Autonomy: AI agents can operate independently, without direct human control or intervention, to achieve their goals. Let’s compare a typical LLM like ChatGPT4 to an Agent built with the OpenAI API. They would work similarly when asked a simple question requiring a definitive answer, essentially because they “find” the references to it in their training dataset. But, as soon as they’re given a task, or asked a question that can’t be answered without some additional research, the difference becomes more clear. Imagine you’ve asked the GPT and your Agent how to fix world hunger. GPT is likely going to provide the most common answer available on the web statistically when an Agentic AI might have another approach. It would start self-prompting some additional questions: does the hunger reasoning in the new world have the same underlying reasoning compared to the countries located in the old world? It could use the internet to check if there are any recent events, like wars or pandemics which affected the state of hunger in the world. After doing some initial research, it would try to find a solution for each specific group of people and combine them all in one complete response. ### AI Agents vs LLMs As you can see from the example above, the AI Agent is one step closer to AGI compared to LLM, due to its ability to self-prompt, use other available tools like the internet, other LLMs, and sometimes a database to deepen the knowledge on a subject before providing an answer. AI agents can analyze the surroundings and context, reason about available information, and take action to maximize their chances of success. Unlike transformers, which are specialized for processing text, AI agents have a broader range of applications, including robotics, gaming, virtual assistants, and autonomous vehicles. In the example above we mention that the AI agent was built with an OpenAI API - which is another key difference between agentic AIs and a typical chatbot style LLM. The more complicated the task is, the more models and tools the Agent would require to use to solve them, and the communication between them is happening through API calls. We see a future where agents become increasingly autonomous - they no longer require detailed, step-by-step instructions from the person and can decide themselves what API or even another agent to create or query to get the job done. Perhaps, most of the users of those APIs and the internet itself won’t be people in the future, rather agents working on behalf of people! To wrap it up: while LLMs exhibit remarkable capabilities in language-related tasks, AI agents demonstrate versatility and adaptability in diverse real-world scenarios, where achieving desired outcomes through creative solutions is crucial. # The Coming Age of Agentic AI To combine with one of the previous articles? ## **The Coming Age of Agentic AI** Recent advances in generative Artificial Intelligence (AI), using Large Language Models (LLMs) based on the Transformer architecture, have led to significant improvements in natural language chatbots, as exemplified by ChatGPT. At the same time, these LLMs are being increasingly applied towards the development of Agentic AI — AI systems that are designed to perform tasks autonomously, make decisions, or take actions on behalf of users or other entities. Unlike chatbots, which can only answer questions, agents can perform tasks on behalf of their users. This trend captures both the development of dedicated agents and the gradual agentification of existing chatbots, such as ChatGPT. Early toy examples of dedicated AI agents included Baby AGI and Auto-GPT, which while interesting experiments were unable to solve all but the simplest of tasks. Over time, more advanced and capable agents have been introduced, including those built using the OpenAI Assistants API and Custom GPTs, the Rabbit R1 hardware-based mobile agent, or bespoke agents and agent networks built with developer frameworks like Langchain and Microsoft’s Autogen. These advances reflect several key trends which are becoming increasing apparent. ### **4 Emerging Trends** 1. *Rapidly Improving Capabilities:* As the capabilites of the underlying LLMs continue to improve, alongside our understanding of how to harness them through agentic software architectures, the capabilites of AI are increasing multiplicatively (cite paper). Narrow agents are giving way to truly generalist agents, which are beginning to look like Samantha, the personal OS imagined in the popular movie *Her.* 2. *Widespread Adoption of Agents*: As the usefulness of AI agents continue to improve they will quickly become widely adopted. While ChatGPT was the fastest app in history to reach 100 million users, when OpenAI later launched GPTs (agents) over three million had already been developed at luanch. Rabbit R1 has already sold through six batches of pre-orders and is poised to replace the smartphone as our everyday personal device. 3. *Increasing Reliance on Agents*: As we delegate more and more responsibility to agents they will become an integral part of our daily lives. They will act as our personal digital assistants and trusted companions. They will mediate our interaction with the digital world, and by extension, our interaction with other humans online. To do so, they will need access to our online identities, accounts, and private credentials. 4. *Agents will become the UI*: As agents become more capable, widespread, and integrated into everything we do, they will become the standard User Interface (UI) *for* *all software*, replacing traditional graphical user interfaces such as mobile apps, web browsers, and desktop operating systems. ### **Agentic AI Safety** For these reasons, AI experts are becoming increasingly concerned about the risks associated with mass adoption of AI agents. These concerns have led to early proposals to define a [governance framework for Agentic AI.](https://cdn.openai.com/papers/practices-for-governing-agentic-ai-systems.pdf) # Open vs Closed Models ## **Open Large Language Models (LLMs)** Open LLMs are accessible to the public or specific research communities, allowing for broad usage, experimentation, and study. These models often come with detailed documentation, source code, and sometimes even the trained parameters or datasets used in their development. Open LLMs promote transparency, innovation, and collaborative research, as they enable developers, researchers, and companies to understand the model's workings, adapt it to new applications, and contribute to its improvement. Examples include models released by academic institutions or open-source initiatives. ## **Closed Large Language Models (LLMs)** Closed LLMs, on the other hand, are proprietary systems developed and owned by organizations that restrict access to their underlying code, training data, and operational mechanisms. These models are often commercialized or used exclusively within the confines of the owning entity, with access provided as a service or through an API under specific terms of use. Closed LLMs prioritize protecting intellectual property, competitive advantage, and commercial interests. The inner workings and data of these models are not transparent to the public, which can limit external innovation and scrutiny. The primary difference between open and closed LLMs lies in their accessibility and transparency. Open LLMs foster an environment of shared knowledge and collective advancement, making it easier for the broader community to innovate, audit for biases or errors, and understand AI's impact. They contribute to the democratization of AI technology, allowing more stakeholders to partake in its development and application. Conversely, closed LLMs control and limit access to protect proprietary interests, which can accelerate the development of highly specialized applications and services within a competitive market. However, this approach can also stifle external innovation and raises concerns about transparency, ethical use, and the potential for biases hidden within the model's black box. ### The fear surrounding the use of closed models * **Lack of Transparency**: Closed models do not provide insight into their internal workings, training data, or algorithms. This opacity makes it difficult for external parties to understand how decisions are made, potentially hiding biases, errors, or unethical reasoning paths. * **Bias and Fairness**: Without access to the model and its training data, it's challenging to audit these systems for bias or fairness issues. Biased training data can lead to skewed outputs, perpetuating stereotypes or unfair treatment across different demographic groups. * **Accountability**: When something goes wrong, such as the model generating harmful or incorrect outputs, the lack of transparency in closed models complicates pinpointing the source of the issue. This can make it difficult to hold the creators or operators of these models accountable. * **Innovation Stifling**: Closed models limit the ability of the broader community to learn from, improve upon, or even challenge the technology. This can stifle innovation and prevent the emergence of diverse approaches to problem-solving within the field of AI. * **Dependency and Control**: Relying on closed models can lead to dependency on specific vendors or creators for updates, improvements, or even the continued availability of the service. This dependency can give disproportionate control and influence to a few entities, raising concerns about monopoly power and its implications for competition and choice. * **Ethical Use and Misuse**: Closed models, by their nature, make it hard to assess whether they're being used ethically and responsibly. There's a fear that without sufficient oversight, these models could be deployed in ways that infringe on privacy, manipulate information, or harm individuals or groups. * **Security Risks**: While not exclusive to closed models, the opacity of such systems can also obscure vulnerabilities or flaws that could be exploited maliciously. Open scrutiny is often a critical component of identifying and addressing security issues. The crux of the concern lies in the balance between protecting intellectual property and the broader implications of deploying powerful AI technologies without adequate oversight, transparency, or opportunities for external evaluation. These fears underscore the need for ethical considerations, regulatory frameworks, and mechanisms for accountability in the development and deployment of AI systems. # Provenance in a Generative World ## The Rise of Fakes The rising tide of AI-generated content poses an existential threat to the integrity and authenticity of digital information. As AI becomes more sophisticated and accessible, the ability to mass-produce convincing yet entirely artificial content has the potential to erode public trust and disrupt industries reliant on genuine content creation. Establishing **provenance** - the record or documentation of where something originated and how it has been handled or modified over time - is crucial to combating this threat. ### Organizations Organizations like the Content Authenticity Initiative (CAI) and the Coalition for Content Provenance and Authenticity (C2PA) are at the vanguard of combating this crisis. * [**Coalition for Content Provenance and Authenticity (C2PA)**](https://c2pa.org/)**:** C2PA is a joint project involving media and tech companies working on open standards to certify the source and history of online content. * [**Content Authenticity Initiative (CAI)**](https://contentauthenticity.org/)**:** The CAI is an Adobe-led project developing technology to provide provenance for digital media. Google, Meta, OpenAI have all pledged to implemented C2PA. Yet, in their most recent [creator credentials call](https://www.linkedin.com/events/contentauthenticityinitiative-t7151727657322221570/), the C2PA core contributors confirmed that detecting generated content is a losing battle. Essentially, the cutting edge thinkers in the space have accepted that there is no good way to determine an image's provenance from the image data alone. Instead, there is a consensus that the war will be won by *adding* provenance data in a secure way. This is where Auto ID comes into play… # AI Empowering Bad Actors ## DeepFake Attacks Artificial intelligence is rapidly advancing, bringing both immense potential and alarming risks. As AI systems grow more sophisticated, they empower malicious actors like scammers, fraudsters, and those seeking to undermine democratic processes. Deepfake technology powered by AI can generate highly realistic yet completely fabricated video and audio content to deceive people. [In one chilling case](https://incode.com/blog/25-million-deepfake-fraud-hong-kong/), a Hong Kong finance firm fell victim to a $25 million deepfake fraud scam. ## Problems with Biometric ID Other networks have emerged approaching the identity problem with [personally invasive techniques](https://www.infosecurity-magazine.com/news/goldpickaxe-trojan-biometric/). WorldCoin's iris-scanning biometric identity network aim to provide a secure form of identification, yet they also raise significant privacy and civil liberties concerns. By requiring the collection of highly sensitive biometric data linked to people's physical identities, such centralized databases create risks if the information is abused by bad actors. [Deepfake AI](https://www.gao.gov/assets/gao-20-379sp.pdf) could potentially exploit the biometric data to generate utterly convincing impersonations of specific individuals for nefarious purposes like fraud, framing innocents for crimes, or producing incendiary disinformation content designed to sow social discord. Authoritarian regimes could pair deepfakes with the biometric data to fabricate fake "evidence" persecuting dissidents or minority groups. Given AI's potent capabilities in this domain, amassing centralized biometric databases provides a concerning attack vector that malicious actors could weaponize for large-scale abuse and subjugation if accessed ## LLM Misinformation Consequences Large language models can also proliferate misinformation and disinformation at an unprecedented scale, with potentially catastrophic consequences during election cycles. As a U.S. Government report warned, AI-generated misinformation could severely disrupt fair elections by flooding the information landscape with fake content indistinguishable from the truth. This threat has already begun manifesting, with major tech companies like Google and OpenAI [detecting widespread AI-enabled disinformation campaigns](https://fortune.com/2024/02/27/election-misinformation-genai-chatbots-google-openai/) attempting to sway public opinion on political issues. The ramifications of AI being weaponized by bad actors are severe and far-reaching. Safeguards must be implemented to prevent such abuses and uphold trust as AI capabilities grow exponential. # Proof-of-Personhood ## Introduction to Proof-of-Personhood Proof of Personhood is a concept in the digital world designed to verify that a user of a service or participant in an activity is indeed a human being, and uniquely so. Imagine you're in a crowded virtual room where everyone wears masks. Some are real people like you, but some are clever robots or duplicates of real people trying to pretend they're human. Proof of Personhood is like a special key given only to real humans to ensure that each person has equal influence or rights, without being overshadowed by AI or other individuals trying to game the system by pretending to be another person. Overall, Proof of Personhood attempts to bring the principle of "one person, one vote" to the digital domain, fostering environments that are fair, democratic, and respectful of human participation. To read more about the Proof-of-Personhood particularly based on World ID, refer to [this article](https://vitalik.eth.limo/general/2023/07/24/biometric.html) by Vitalik Buterin. ### Why do we need to have a proof-of-personhood This concept is crucial for four reasons: 1. **Democracy and Fairness**: In voting systems or decision-making processes online, ensuring each person has one and only one vote prevents manipulation and maintains fairness. 2. **Reducing Spam and Abuse**: By verifying human identity, systems can reduce the amount of spam or abusive content generated by bots. 3. **Resource Allocation**: In scenarios where resources are limited (like in online contests or giveaways), Proof of Personhood helps ensure these resources are distributed fairly among real humans. 4. **Enhancing Security**: It adds a layer of security by making it harder for malicious entities to create multiple fake accounts for fraudulent purposes. Proof of personhood is valuable because it solves a lot of anti-spam and anti-concentration-of-power problems that many people have, in a way that avoids dependence on centralized authorities and reveals the minimal information possible. ### Existing projects and approaches to proof-of-personhood (taken from the article linked above) * [**Proof of Humanity**](https://proofofhumanity.id/): you upload a video of yourself, and provide a deposit. To be approved, an existing user needs to vouch for you, and an amount of time needs to pass during which you can be challenged. If there is a challenge, a [Kleros decentralized court](https://kleros.io/about/) determines whether or not your video was genuine; if it is not, you lose your deposit and the challenger gets a reward. * [**BrightID**](https://brightid.gitbook.io/brightid/getting-verified): you join a video call "verification party" with other users, where everyone verifies each other. Higher levels of verification are available via [Bitu](https://medium.com/brightid/what-is-markaz-verification-level-47397372c8eb), a system in which you can get verified if enough other Bitu-verified users vouch for you. * [**Idena**](http://idena.network/): you play a captcha game at a specific point in time (to prevent people from participating multiple times); part of the captcha game involves creating and verifying captchas that will then be used to verify others. * [**Circles**](https://circles.garden/): an existing Circles user vouches for you. Circles is unique in that it does not attempt to create a "globally verifiable ID"; rather, it creates a graph of trust relationships, where someone's trustworthiness can only be verified from the perspective of your own position in that graph. * **Privacy Concerns**: Many Proof-of-Personhood systems require users to submit personal information or undergo verification processes that could compromise their privacy. Projects like WorldCoin, which use biometric data, have raised concerns about how this sensitive information is stored, protected, and potentially misused. * **Exclusion and Accessibility**: These systems might inadvertently exclude individuals who lack access to the necessary technology or are uncomfortable with the verification process. For example, people without smartphones or those who are wary of providing biometric data might be left out. * **Implementation Complexity**: Setting up a Proof-of-Personhood system that is both secure and user-friendly is complex. The challenge of distinguishing between individuals without infringing on their privacy or freedom can lead to technical and ethical dilemmas. * **False Positives/Negatives**: No system is perfect, and there's always a risk of incorrectly identifying someone as a bot (false positive) or allowing a sophisticated bot to pass as human (false negative). These errors could lead to unfair treatment or system manipulation. * **Scalability Issues**: As the community around a Proof-of-Personhood system grows, maintaining the integrity and efficiency of the verification process becomes more challenging. The system needs to scale without compromising on speed, accuracy, or user experience. * **Centralization Risks**: Some Proof-of-Personhood projects rely on centralized databases or verification authorities, which could become targets for attacks or abuse. This centralization contradicts the decentralized ethos of many online communities and blockchain projects. * **Legal and Regulatory Challenges**: Navigating the legal landscape with technologies that handle sensitive personal data, especially on a global scale, can be fraught with challenges. Compliance with laws like GDPR in Europe, which protects individual data privacy, adds another layer of complexity. * **Cultural and Ethical Implications**: The concept of what constitutes proof of one's personhood varies culturally and philosophically. Projects like these delve into deep ethical territories about identity and existence in the digital age, which may not have universally accepted answers. # Identity & Security #### # DID & Verifiable Credentials ## **Self-Sovereign Identity (SSI):** Normally, when you want to prove who you are, you show an ID card or document that was issued by someone else, like the government or a company. This is called a "centralized identity" because those organizations are in control of your identity. With self-sovereign identity, instead of getting your ID from someone else, you create your own "decentralized digital identity" on a registry such as a blockchain or distributed ledger. This identity is just for you - no one else controls or owns it. You store information proving who you are, like your name, age, qualifications etc. in a digital wallet or repository on your phone or computer. This info is secured using advanced crypto techniques like public/private key pairs. When you need to prove your identity to someone, like when renting an apartment, you can securely share just the required details from your digital wallet. You decide what to share and with who - giving you much more control over your personal data compared to traditional ID methods. Self-sovereign identity aims to make identification more trustworthy, privacy-preserving and return ownership of your identity to you rather than organizations. Technical implementations including decentralized identifiers (DIDs), verifiable credentials, and zero-knowledge proofs are used to accomplish this vision. [Zero-knowledge proofs](https://chain.link/education/zero-knowledge-proof-zkp) are a way to prove something is true without revealing any information about it. Imagine you have a secret code to open a lock, but you don't want to tell anyone the code. With zero-knowledge proofs, you can prove to someone that you know the code without actually showing them the code.
### Decentralized Identifiers When you want to identify yourself online, you use things like a username, email address, or website URL. These are analogous to your "digital name". But the problem is, these identities are provided and controlled by centralized companies or organizations. For example, Google owns your Gmail address. [Decentralized Identifiers](https://www.w3.org/TR/did-core/) or DIDs are a new type of digital identity that doesn't belong to any company. Instead of someone giving you an identity, with DIDs you create your own "self-sovereign" identity using special cryptography. A DID looks something like this weird string: "did:example:123456789abcdefghi". It's generated using blockchain-like distributed ledger technology, rather than coming from a centralized source. DIDs allow you to link [Verifiable Credentials](https://www.w3.org/TR/vc-data-model-2.0/) (VCs) containing verified claims about yourself like your name, age, qualifications etc. VCs are digital credentials that are cryptographically verified and linked to your DID. Having your own DID means you remain in full control of your digital identity. It can't be taken away, censored, or turned off by anyone else. You're not locked into using a particular company's service or ecosystem either. DIDs allow you to prove things about your identity in a trusted, decentralized way using advanced crypto like digital signatures and verifiable credentials. They help solve problems of identity and data ownership on the internet. ### **Identity and Access Management (IAM)** Imagine your house has many rooms and some rooms are off-limits or private. Identity and Access Management (IAM) is a system that controls who is allowed to enter which rooms and what they can do there. In a company or organization, there are different users like employees, contractors, partners etc. IAM is how the company manages the identities of all these users through a centralized system. First, IAM verifies the identity of each user through authentication techniques like passwords, biometrics, security tokens etc. This proves they are who they say they are. Once authenticated, IAM then uses authorization processes to grant or deny the user access to specific resources like computer systems, data, applications based on their role or privileges within the organization. An IAM system assigns roles and permissions to users. For example, regular employees may get access to basic resources, while IT admins get more powerful access capabilities. Key IAM components include a central user directory, identity repositories, access management tools, password policies, and audit logging mechanisms to track who accessed what. IAM helps securely manage user identities and access rights across the entire enterprise in one place according to policies and regulatory compliance requirements. This protects sensitive data and assets. So in simple terms, IAM is the gatekeeper that controls digital entry and exit while maintaining proper identity assurances within an organizational environment. # OAuth and OIDC ## O Auth 2.0 [OAuth 2.0](https://oauth.net/2/) is an industry-standard protocol for authorization that provides a secure way for applications to access user data or perform actions on behalf of the user without requiring the user to share their credentials directly with the application. OAuth 2.0 allows users to grant limited access to their accounts or resources to third-party applications through an authorization server. The significance of OAuth 2.0 lies in its ability to enhance security and user privacy while enabling seamless integration of third-party services. By leveraging OAuth 2.0, users can selectively grant permissions to applications without exposing their credentials, reducing the risk of credential theft or misuse. Additionally, OAuth 2.0 simplifies the authentication process for users, as they only need to authenticate with the authorization server once, rather than providing their credentials to multiple applications. This protocol has become widely adopted across various platforms and industries, enabling specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.
## **OpenID Connect (OIDC)** While OAuth 2.0 focuses on authorization, [OIDC](https://www.microsoft.com/en-us/security/business/security-101/what-is-openid-connect-oidc) adds an identity layer to the process, allowing applications to receive identity information from an authorization server. The significance of OIDC lies in its ability to simplify the authentication process for both developers and users. By leveraging OIDC, developers can offload the complex task of managing user identities to a trusted identity provider, reducing the risk of security vulnerabilities and ensuring compliance with industry standards. For users, OIDC streamlines the login experience by allowing them to authenticate once with the identity provider and seamlessly access multiple applications without the need to create and manage separate credentials for each service. OIDC provides a standardized format for identity tokens, which contain claims (pieces of information) about the authenticated user, such as their name, email address, and other relevant details. These tokens can be easily shared and verified by applications, enabling a more secure and efficient way of managing user identities across different platforms and services. As a result, OIDC has gained widespread adoption, particularly in enterprise environments and cloud-based applications, where secure and scalable identity management is crucial.
# Public Key Infrastructure #### Public Key Infrastructure & Transport Layer Security Public Key Infrastructure (PKI) is like a special club that websites need to join to prove they are legitimate and not trying to trick you. When a website wants to join the club, they get a membership card called a "digital certificate" from the club leader called a Certificate Authority (CA). This certificate has a secret code called a public key that only the real website knows. When you visit a website, your web browser checks if they have a valid membership card or certificate from the club. If they do, it means you can trust and safely share private information with the website. It's like showing up to a friend's house and checking their ID to make sure they live there before going inside.\ \ PKI also consists of Registration Authorities (RAs) that verify the identity of entities requesting a certificate before the CA issues it. There are repositories for storing and retrieving certificates as well as Certificate Revocation Lists (CRLs), which are essential for maintaining the integrity of the system by listing certificates that are no longer trusted.\ \ \ **Transport Layer Security (TLS)** Transport Layer Security (TLS) is a secret code language that your computer and a website use when talking over the internet. It scrambles up your conversation into an encrypted message that bad people can't understand if they try to snoop. TLS uses those membership cards or certificates from PKI to make sure your computer is really talking to the correct website through a process called authentication. It's like you and your friend making up a silly code language that only you two understand. That way, if someone tried to listen to your conversations, it would just sound like gibberish to them. Showing the PKI certificate proves you're talking to the right friend. The encrypted conversation using TLS is like the code language.\ \ TLS almost works as a "handshake", where the server and client exchange keys, negotiate encryption algorithms, and verify each other's certificates. This process ensures that the communication channel is secure before any data is exchanged.
# Web3 # What is a Blockchain? ## Simple Analogy Imagine you have a shared notebook that you and your friends write in to keep track of all the trades of stickers, cards, or any items you exchange. Each page of the notebook records a list of who traded what with whom, when and at what price and once the page is full, you move on to the next one. Now, to make sure no one can cheat by changing a trade recorded on any page, each new page has a special code that is created by looking at all the trades on the previous page and using a super-secret recipe (or algorithm) to generate this code. This special code is then written at the top of the next page, linking the two pages together. This way, if someone tries to change a trade on a previous page, the special code won't match anymore, and everyone will know something was altered. This notebook is like a **blockchain**. In the blockchain world, each page of the notebook is called a "block," and the special code that links one block to the next is called a "hash." The entire list of pages, or blocks, is what forms the "chain," hence the name blockchain. ## **Key Points of a Blockchain:** * **Decentralized**: Unlike a single notebook kept by one person, the blockchain is like having thousands of identical notebooks distributed across a vast network of computers. Everyone can see all the transactions, ensuring transparency and making it extremely difficult for anyone to cheat. * **Secure**: The special codes (hashes) that link the blocks together are created using complex mathematical puzzles. These puzzles are so hard that they require a massive amount of computing power to solve, which secures the blockchain against tampering. * **Immutable**: Once something is written in the blockchain, it cannot be changed or removed, making the record of transactions permanent and tamper-proof. * **Consensus**: For a new block to be added to the chain, the majority of the computers in the network have to agree that the transactions are valid. This agreement process is called "consensus," and it helps to further secure the system. ## Extra Resources For those eager to dive deeper into the intricacies of blockchain technology, explore the following resources: * [Investopedia's Blockchain Guide](https://www.investopedia.com/terms/b/blockchain.asp): Provides a comprehensive overview of blockchain technology and its key components. * [Bitcoin's Original Whitepaper](https://bitcoinwhitepaper.co/): Though technical, this document by Satoshi Nakamoto introduced blockchain technology to the world through Bitcoin. * [IBM's Blockchain Basics](https://www.ibm.com/topics/what-is-blockchain): Offers a detailed yet accessible introduction to blockchain technology, including its applications beyond cryptocurrencies. Blockchain technology isn't just the foundation of cryptocurrencies like Bitcoin or Ethereum; it has the potential to revolutionize various industries by providing a new way to record and verify transactions of all kinds, from financial trades to supply chain management and even voting systems. Its unique combination of transparency, security, and decentralization makes it a powerful tool for creating trust in digital interactions. # The Blockchain Trilemma and the Cost of Scalability ## Blockchain Trilemma The concept of the **"Blockchain Trilemma"** is like a challenging puzzle in a video game, where you must balance three important powers, but you can't have them all at full strength at the same time. In the world of blockchain, these three powers are **security, scalability, and decentralization**. The trilemma suggests that any blockchain system can only achieve two of these attributes at their peak... **Understanding the Trilemma:** 1. **Security**: This is the shield of the blockchain, protecting it from attacks and ensuring that all transactions are safe and untampered with. High security means that it's nearly impossible for hackers to change transaction records or attack the network. 2. **Scalability**: Think of this as the speed and space of the blockchain. Scalability means the blockchain can handle a large number of transactions quickly and efficiently, without getting bogged down. 3. **Decentralization**: This represents the distribution of power across many computers (or nodes) in the network, rather than having it controlled by just a few. This ensures that no single entity has too much control, keeping the system fair and democratic. ### **The Puzzle of Balance:** * **Security and Decentralization without Scalability**: Imagine a highly secure and widely distributed blockchain. It's very safe and not controlled by just one party. However, because it's spread out and each transaction needs to be confirmed by many nodes, it starts to slow down when too many transactions pile up. * **Scalability and Security without Decentralization**: Now picture a blockchain that's very fast and secure, but most of the control is with a few nodes. This makes transactions quick and safe, but it's not as democratic or resistant to manipulation by those few in control. * **Decentralization and Scalability without Security**: Lastly, imagine a blockchain that's fast and spread out across many nodes, making it quick and democratic. However, this setup might make it easier for attackers to find vulnerabilities, as ensuring tight security across a wide, fast-moving network is challenging. ### Extra Resources For those interested in learning more on this concept and exploring potential solutions, the following resources are invaluable: * [Blockchain Trilemma Explained](https://www.liminalcustody.com/blog/blockchain-trilemma-explained/): Provides a more robust look into the subject. * Ethereum Founder [Vitalik Buterin's](https://vitalik.eth.limo/) Explanation: He coined the term and discusses it frequently in his writings and interviews, providing keen insights into the challenges and potential future solutions for the trilemma. * [Blockchain Research Institutes and Academic Papers](https://www.blockchainresearchinstitute.org/): These institutions often publish detailed research on blockchain technology, including discussions on the trilemma and proposed innovations to address it. The blockchain trilemma remains one of the most significant challenges in the field of blockchain technology. It serves as a guiding problem for developers and researchers striving to innovate and create more balanced systems. As the blockchain ecosystem evolves, finding a solution or an acceptable balance among these three critical attributes continues to be a primary focus for the future development of blockchain technologies. # What is a Cryptocurrency ## Features of Cryptocurrency A cryptocurrency is a form of digital or virtual currency that is secured by [cryptography](https://www.fortinet.com/resources/cyberglossary/what-is-cryptography#:~:text=Cryptography%20is%20the%20process%20of,%2C%20computer%20passwords%2C%20and%20ecommerce.) making it nearly impossible to counterfeit or double-spend. Cryptocurrencies are decentralized networks based on blockchain technology. Here are 6 key features of cryptocurrencies: 1. Decentralized: Cryptocurrencies are not issued or controlled by any central authority like a government or bank. They operate in a decentralized manner across a peer-to-peer network. 2. Secure: Transactions in cryptocurrencies are secured through the use of cryptography, making them highly secure and difficult to counterfeit. 3. Pseudonymous: Cryptocurrency transactions are recorded in a public ledger (blockchain) without revealing the real-world identities of the parties involved. Users can hold multiple public addresses or wallets to receive and send funds. 4. Transparent: The blockchain ledger is transparent, meaning that anyone can view all transactions on the network. 5. Limited Supply: Most cryptocurrencies have a limited and predetermined supply, which is defined by code and cannot be manipulated by any central authority. 6. Global: Cryptocurrencies can be transferred globally, rapidly, and at a relatively low cost compared to traditional cross-border money transfers. Some of the most well-known cryptocurrencies include Bitcoin (BTC) and Ethereum (ETH). Cryptocurrencies have gained popularity due to their potential for secure, borderless, anonymous transactions and as an alternative to traditional fiat currencies. However, their use and regulation remain a subject of ongoing debate, with concerns around price volatility, potential use in illicit activities, and environmental impact from the high energy consumption required for mining some cryptocurrencies. Obtaining cryptocurrency can be achieved primarily through two methods: buying and mining or farming, in some contexts. ## **Are crypto coins and tokens the same?** Crypto coins, such as Bitcoin or Ethereum, are native to their own blockchain. They are designed to function as digital currency and are used to store value or make transactions. On the other hand, crypto tokens are created on existing blockchains using the framework provided by platforms like Ethereum. Tokens can serve a variety of purposes beyond just transactions; they can represent assets, provide utility within applications, or signify ownership or rights. Tokens are versatile and can be used in applications such as decentralized finance (DeFi) services, voting systems, or as digital representations of physical assets. # General Information about SDK ## What is an SDK An SDK, or Software Development Kit, is like a treasure chest for developers, packed with all the tools, code samples, and documentation needed to embark on the adventure of building apps. It's your all-in-one toolkit designed to streamline the creation process, whether you're developing sleek mobile apps, powerful software, or integrating cool features into existing platforms. Imagine having a magic wand that not only guides you through the forests of code but also empowers you to conjure up applications with ease, efficiency, and creativity. That's the power of an SDK in the hands of a developer: turning the complex journey of app development into a smooth and exciting quest for innovation. ### Components of SDK While one SDK might be different from another, they all tend to have a similar structure. * **Libraries and Frameworks**\ When coding, there is a lot of repetitive code that every programmer does not want to write. At the same time, it’s very important to not make a single mistake in some of the core functions, since your whole application depends on them! That is exactly why the set of the most commonly performed actions is wrapped in a reusable function and made available to everyone via the API call to the SDK. They save you from having to reinvent the wheel, allowing you to focus on unique features and delegate complex repetitive tasks to it. * **Development Tools**\ Anything from your code editor to your compiler is a development tool. They make every programmer's job more enjoyable and speed up the development process, turning it into a smooth and error-free journey. * **Documentation**\ Documentation is one of the key components of an SDK. You might have the best SDK in the world code-wise, filled with the most usable and important functions but there is no meaning to them if your documentation does not explain how to use it properly. Good documentation should be easy to navigate and to follow, so that every developer could be focused on building, rather than searching. * **Code Samples and Tutorials**\ One of the best ways to introduce an SDK is to show users what apps could be built with it and what the main use cases are for working with the SDK. Every person is built differently, and many people find code examples and application examples the best way to start building on their own. Together, these components of an SDK empower developers with the knowledge, tools, and "magic" needed to build complete applications fast, securely, and with great joy! # What is a DAO? **What is a DAO?** A DAO, or Decentralized Autonomous Organization, is an organization that is governed by rules encoded as computer programs called [smart contracts](https://www.investopedia.com/terms/s/smart-contracts.asp) on a blockchain network. Here's how a DAO typically works: 1. Smart Contract Rules: The core of a DAO is its smart contract, which defines the organizational rules, decision-making processes, and how the DAO's funds can be spent. These rules are immutable and transparent on the blockchain. 2. Token-based Voting: DAOs often have a native cryptocurrency token that represents governance rights. Token holders can vote on proposals or decisions put forth by the DAO, with voting power proportional to the number of tokens held. 3. Proposal Submission: Anyone can typically submit proposals for the DAO to consider, such as changes to the DAO's code, funding requests, or other governance decisions. 4. Voting Period: Once a proposal is submitted, there is a predetermined voting period during which token holders can cast their votes. 5. Execution of Approved Proposals: If a proposal passes the voting threshold (e.g., a majority or [supermajority](https://en.wikipedia.org/wiki/Supermajority) of votes), the DAO's smart contract automatically executes the approved action or change. 6. Funding and Treasuries: DAOs can have a shared treasury funded by token sales, fees, or other revenue sources. Approved proposals can request funds from this treasury for projects, hiring, or other expenses. 7. Transparency and Immutability: All DAO activities, including proposals, votes, and financial transactions, are recorded on the blockchain, providing transparency and an immutable ledger. The key principles of a DAO are decentralized governance, autonomous execution of rules through smart contracts, and transparency of operations on the blockchain. This allows for collective decision-making and management without a centralized authority, enabling new forms of decentralized organizations and collaboration. If we boil intelligence down to the decisions it makes being a function of its knowledge and alignment, along with ensuring voting is as fast and frictionless as possible, we can see that a DAO can facilitate much more than the traditional use cases such as funding or protocol governance. # Challenges of Participating in a DAO Participating in a DAO (Decentralized Autonomous Organization) can present several challenges: 1. Technical Complexity: DAOs operate on [blockchain technology](/additional-learning/web3/what-is-a-blockchain) and smart contracts, which can be technically complex and difficult to understand for non-technical users. Participating in governance processes, such as voting on proposals, may require a certain level of technical knowledge. 2. Token Ownership: To participate in a DAO's governance, users typically need to hold the DAO's native cryptocurrency tokens. Acquiring and managing these tokens can be a barrier for some individuals, especially if the tokens are expensive or have limited availability. 3. Decentralized Decision-making: DAOs rely on decentralized decision-making processes, which can be slower and more complicated than traditional centralized decision-making. Reaching consensus among a large number of stakeholders with diverse interests can be challenging. 4. Governance Challenges: DAOs may face governance challenges, such as low voter participation, voter apathy, or the risk of whales (large token holders) having disproportionate influence on decision-making. 5. Regulatory Uncertainty: The regulatory landscape surrounding DAOs is still evolving, and there may be uncertainties around legal implications, tax considerations, and compliance requirements. 6. Security Risks: Smart contracts and blockchain systems are vulnerable to potential security risks, such as coding errors, exploits, or hacking attempts, which could compromise the DAO's funds or operations. 7. Information Asymmetry: Some DAO participants may have more information or expertise than others, leading to potential information asymmetries that could influence decision-making processes. 8. Coordination and Communication: Coordinating and communicating effectively among a decentralized network of participants can be challenging, especially when they are geographically distributed and may have different languages and cultural backgrounds. While DAOs offer the potential for transparent and decentralized governance, participating in them requires a certain level of technical knowledge, commitment, and an understanding of the challenges involved in decentralized decision-making processes. Many of the issues cited above would be mitigated if there were a way to participate in a DAO that was accessible, simple and fast which could be delivered to the masses. Increasing voter education and context about the issue they are voting on and how it aligns with their own values and goals will improve the quality of the decisions being made. As will providing that detail in the user’s native language. Removing as much friction and complexity as possible will also go a long way to increasing voter turn-out which improves decentralization and stakeholder engagement. Knocking down as many barriers to having your voice heard as possible will enable the next level of harnessing knowledge and opinion at scale. # Feedback Form Autonomys Academy feedback form The Autonomys Academy is always being updated and improved, and we're eager for your input. If you find anything that is unclear, incorrect or incomplete, or if you have any other feedback, please let us know. Thanks! {% embed url="" %}