# Radicle

> Radicle is an open-source, peer-to-peer code collaboration protocol and stack built on Git that enables local-first, self-certifying repositories, cryptographic identities, and gossip-based discovery without a centralized host.

- Canonical URL: https://iq.wiki/wiki/radicle
- Categories: Projects & Protocols
- Tags: Ethereum, Identity, Infrastructure
- Created: 2026-10-09T17:00:58.137Z
- Last updated: 2026-10-09T17:08:13.460Z
- Source: IQ.wiki — the world's largest blockchain and crypto encyclopedia (https://iq.wiki)

---

**Radicle** is a peer-to-peer protocol for hosting and collaborating on Git repositories without relying on centralized code hosting platforms. It uses cryptographic identities, distributed networking, and local-first storage to support code collaboration, repository verification, and censorship resistance. [\[1\]](#cite-id-ek47y6ru77)  

## Overview

Radicle Protocol is a decentralized, peer-to-peer network for publishing and collaborating on code, built on Git. Rather than relying on centralized hosting services, participants run [nodes](https://iq.wiki/wiki/node) on their own devices to store and synchronize repositories, including related collaboration data such as issues and patches. The network uses a gossip protocol for discovering peers and repositories, while Git’s replication mechanisms support data exchange between [nodes](https://iq.wiki/wiki/node). Its architecture remains compatible with existing Git tools and workflows, as long as at least one online peer hosts the repository being accessed.

Radicle uses a local-first architecture that allows users to access their repositories without an internet connection. Each repository has a unique identifier, and actions such as committing code, commenting on issues, and submitting patches are cryptographically signed so that other participants can verify their authenticity and origin. This design allows collaboration and data sharing without depending on a centralized authority to host repositories or manage project activity. Although its primary focus is code publishing and collaboration, the protocol can also support other distributed applications, including knowledge sharing, project coordination, and dataset collaboration. [\[4\]](#cite-id-cfpbz24tz6) 

## Architecture

![](https://ipfs.everipedia.org/ipfs/QmexEuCEkPfiY8VVfdrq9V3FAKTGWF1ZK6D2PD35awuCvW)

### Nodes

Radicle [nodes](https://iq.wiki/wiki/node) are participants in its peer-to-peer network and can act as both clients and servers, hosting Git repositories and synchronizing changes with other [nodes](https://iq.wiki/wiki/node). Each node is identified by a unique Node ID, derived from an Ed25519 public key, while each repository has its own Repository ID. Users control which repositories their nodes store and share through seeding policies that define repository selection, data retention, and synchronization. Individual users can run nodes on personal computers to support their own projects, while dedicated seed [nodes](https://iq.wiki/wiki/node) can provide the wider network or specific communities with continuous access to repositories.

Node identities are generated locally using public-key cryptography and do not require a centralized identity provider, email address, or personal information. The public key serves as the node’s identifier, while the private key authenticates signed messages and must be kept secure. Users can also assign a changeable alias to make their [nodes](https://iq.wiki/wiki/node) easier to recognize. To participate in the network, users install Radicle’s open-source client software, which includes a network client and command-line interface, with an optional web frontend. The reference implementation is written in Rust, and implementations follow the protocol specifications maintained through Radicle Improvement Proposals (RIPs). [\[4\]](#cite-id-cfpbz24tz6) 

### Peer-to-Peer

Radicle uses a local-first, peer-to-peer (P2P) architecture that allows [nodes](https://iq.wiki/wiki/node) to discover one another, exchange repository updates, and synchronize code without relying on a centralized hosting service. Its networking layer uses a gossip protocol to distribute information about available peers, hosted repositories, and repository changes. Signed announcements include node identifiers and timestamps, allowing participants to verify message authenticity and avoid repeatedly relaying messages they have already received. Nodes can temporarily retain and replay announcements to help newly connected or returning peers discover network activity.

Repository metadata is exchanged through gossip, while Git transfers actual code and objects using Git’s replication protocol. Nodes can fetch repository data from peers that host or seed the relevant repositories, with multiple transfers supported over a shared network connection. New [nodes](https://iq.wiki/wiki/node) use bootstrap nodes to discover initial peers and build an address book before participating in regular network discovery. Unlike federated systems, where server operators can influence users’ identities and access to shared services, Radicle lets users keep their own repositories and collaboration data, while seed [nodes](https://iq.wiki/wiki/node) provide interchangeable hosting and replication services. [\[4\]](#cite-id-cfpbz24tz6) 

### Repositories

Radicle repositories are Git repositories shared across its peer-to-peer network, with additional identifiers and metadata used to establish ownership, permissions, and authenticity. They can contain source code, documentation, or other datasets, and each repository is initialized with an identity document that defines its name, description, default branch, and designated delegates. Delegates are individuals, groups, or automated agents identified by decentralized identifiers (DIDs) and are responsible for tasks such as merging patches, resolving issues, and managing repository permissions. Repositories begin with their creator as the initial delegate and can assign authority to multiple delegates, with a specified signature threshold governing changes to the default branch.

Each repository receives a globally unique Repository ID (RID), derived from the initial version of its identity document, which can be updated without changing the identifier. The identity document is stored within the Git repository in a standardized JSON format that supports consistent cryptographic verification. Radicle also supports private repositories by restricting replication to an explicitly authorized set of peers, while repository delegates retain access. Private repository data is not encrypted at rest, so access control relies on limiting which nodes can replicate and access the repository, not on storage encryption. [\[4\]](#cite-id-cfpbz24tz6) 

### Local-First Storage

Radicle uses a local-first storage architecture built on standard Git repositories, allowing users to store, manage, and synchronize repository data directly from their devices. Each repository is stored locally as a bare Git repository, with Git namespaces separating the references associated with individual peers. Each namespace is controlled by its corresponding node, allowing users to maintain their own branches and changes without modifying other peers’ versions. The namespaces share an underlying Git object database, reducing duplicated storage when multiple peers have the same commits or files. Users can work with both a local working copy and a stored copy, synchronizing changes through standard Git commands such as push and fetch.

Users can make changes offline and propagate them to other peers when a node reconnects to the network. Radicle uses a dedicated rad:// URL scheme and a Git remote helper to direct fetch and push operations to the appropriate repository and peer namespace. When a peer is not specified, Git operations can target the repository’s canonical references, representing the version agreed upon by its delegates. This design preserves compatibility with established Git workflows while allowing repository data to be maintained and synchronized without depending on centralized hosting servers. [\[4\]](#cite-id-cfpbz24tz6) 

### Self-Certification

Radicle uses a self-certification model to verify repository authenticity without relying on a centralized hosting service. Each repository’s identity is established through its Repository ID (RID) and identity document, which defines its delegates, default branch, and the signature threshold required to authorize changes. The canonical state of the default branch depends on whether the required number of delegates have signed off on the same commit. For example, if a repository requires approval from two of three delegates, a commit becomes canonical when two delegates publish matching updates to their respective branches. Repository changes are authenticated through cryptographic signatures, including updates to Git references that track branches and collaboration data. Radicle automatically signs a node’s references when they change and stores the signed information under a dedicated Git reference. This lets network participants verify repository updates and determine a repository's authoritative state using its identity information and cryptographic records, without a trusted third party. [\[4\]](#cite-id-cfpbz24tz6) 

### Collaborative Objects

Radicle uses Collaborative Objects (COBs) to support collaboration features that Git does not provide natively, including issue tracking, code reviews, and discussions. These objects are stored directly within repositories and replicated across the peer-to-peer network, keeping collaboration data local-first, user-controlled, and cryptographically signed. Radicle provides three predefined COB types: Issues for tracking bugs and feature requests, Patches for proposing and reviewing code changes, and Identities for managing repository identity documents. Each object is identified by a unique type name and object identifier, and users can define additional types for other collaboration needs.

COBs use Git commit histories to record changes as a directed acyclic graph, allowing multiple users to make updates independently without coordinating through a central server. When peers synchronize, they combine their histories, and the object’s state is reconstructed by processing changes in a deterministic, causally consistent order. This approach uses Git’s existing mechanisms for data integrity and synchronization while helping peers converge on a consistent view of each object, even when updates arrive out of order. The system also supports custom COB types stored in the repository’s refs/cobs hierarchy, allowing developers and organizations to add collaboration features without changing the core protocol. [\[4\]](#cite-id-cfpbz24tz6) 

### Radicle Garden

Radicle Garden is a hosted service that provides always-on [nodes](https://iq.wiki/wiki/node) for the Radicle peer-to-peer network, keeping Git repositories available when users’ personal devices are offline. The service replicates selected repositories to add availability without requiring users to run their own servers. Users retain their local Radicle nodes for signing and managing their work, while Garden [nodes](https://iq.wiki/wiki/node) provide continuous repository seeding. The service can also seed repositories maintained by other users, helping keep projects accessible across the network. Radicle Garden is operated by the Better Internet Foundation, a Swiss nonprofit organization that oversees development of the Radicle Protocol. The service provides an optional hosted alternative to self-managed seed nodes, while its source code remains open source and users can continue to operate their own infrastructure. Hosted [nodes](https://iq.wiki/wiki/node) are located in Europe, and subscription revenue supports the foundation’s work on the continued development of the Radicle Protocol. [\[3\]](#cite-id-nmmyzyxh36)  [\[4\]](#cite-id-cfpbz24tz6) 

## RAD

![](https://ipfs.everipedia.org/ipfs/QmZWJuQhaCLAjGasX6psQgqQse7EiJ6rwqjrcBduGagYvX)

RAD is the native [governance token](https://iq.wiki/wiki/governance-tokens) of the Radicle ecosystem, a decentralized network for code collaboration. It is used to participate in protocol governance and provides holders with fee-related benefits when using certain [Ethereum](https://iq.wiki/wiki/ethereum)-based Radicle protocols. RAD holders can vote on protocol changes and decisions concerning the Radicle Treasury, which holds a significant portion of the token supply. Governance is managed through the Radicle DAO, which uses a governance system derived from the [Compound](https://iq.wiki/wiki/compound) protocol and follows a one-token, one-vote model. Holding RAD also provides discounts or fee exemptions for certain protocol interactions, while users without tokens can still access the protocols by paying the applicable fees. [\[2\]](#cite-id-76bwmhmojv) 

### Tokenomics

RAD has a total supply of 100M tokens and has the following allocation: [\[2\]](#cite-id-76bwmhmojv) 

* **Community Treasury**: 50%
* **Early Supporters**: 20%
* **Team**: 19%
* **Foundation**: 11%