{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Introduction","text":"

Sonr is a decentralized identity network built on the Cosmos-sdk. It has early origins as a peer-to-peer file sharing network, but has since evolved into a platform for decentralized authentication and authorization. The early lessons taught from our file sharing roots are used as our theology for building the Sonr Blockchain.

  1. Cosmos-SDK
  2. Chain-Modules
  3. System-Architecture
  4. Token-Economy
  5. Service-Management
  6. Design-System
  7. Self-Custody
  8. Consumer Launch
"},{"location":"#principles","title":"Principles","text":"
  1. Bitcoin is digital gold
  2. Blockchains are programmable databases with functional operations
  3. Staking is essentially a savings account
  4. The Sonr Network conducts all operations in the $SNR token
  5. Service Delegation subsidizes user wallet operations.
  6. Cryptocurrency has the potential to break the software innovation ceiling
"},{"location":"#the-problem","title":"The Problem","text":"

Centralized identity has led to internet monopolies abusing your trust and privacy.

"},{"location":"#the-solution","title":"The Solution","text":"

A peer-to-peer system for decentralized personal identity with Authentication and Authorization capabilities.

"},{"location":"#what-is-sonr","title":"What is Sonr?","text":"

A privacy preserving, identity system managed by user controlled decentralized vaults which have the flexibility of software wallets with the security of hardware wallets.

"},{"location":"#the-end-goal","title":"The End Goal","text":"

A Data sharing economy where human-specific information has intrinsic value. Services are incentivized to act in good faith in order to obtain quality user data.

"},{"location":"#how-do-we-do-it","title":"How do we do it?","text":"

Provide Internet Citizens with a robust easy to use WebVault which features a crypto wallet, passkey authenticator, and encrypted messages. The WebVault serves as a wrapper over every sensitive intent-based user interaction. The Smart blockchain is responsible for keeping a record of where WebVaults are located, when authorization activity occurs, and which services are allowed over what permissions.

"},{"location":"#the-user-incentive","title":"The User Incentive","text":"

Data is the byproduct of currency exchange in the Information age. Meaning services pay other services for user data or profits in order to enrich their database with complete user personas.

"},{"location":"changelog/","title":"Index","text":""},{"location":"changelog/#v0526-2024-12-13","title":"v0.5.26 (2024-12-13)","text":""},{"location":"changelog/#fix","title":"Fix","text":""},{"location":"changelog/#v0525-2024-12-11","title":"v0.5.25 (2024-12-11)","text":""},{"location":"changelog/#feat","title":"Feat","text":""},{"location":"changelog/#v0524-2024-12-11","title":"v0.5.24 (2024-12-11)","text":""},{"location":"changelog/#feat_1","title":"Feat","text":""},{"location":"changelog/#v0523-2024-12-11","title":"v0.5.23 (2024-12-11)","text":""},{"location":"changelog/#refactor","title":"Refactor","text":""},{"location":"changelog/#v0522-2024-12-11","title":"v0.5.22 (2024-12-11)","text":""},{"location":"changelog/#feat_2","title":"Feat","text":""},{"location":"changelog/#v0521-2024-12-11","title":"v0.5.21 (2024-12-11)","text":""},{"location":"changelog/#feat_3","title":"Feat","text":""},{"location":"changelog/#fix_1","title":"Fix","text":""},{"location":"changelog/#refactor_1","title":"Refactor","text":""},{"location":"changelog/#v0520-2024-12-07","title":"v0.5.20 (2024-12-07)","text":""},{"location":"changelog/#refactor_2","title":"Refactor","text":""},{"location":"changelog/#v0519-2024-12-06","title":"v0.5.19 (2024-12-06)","text":""},{"location":"changelog/#feat_4","title":"Feat","text":""},{"location":"changelog/#fix_2","title":"Fix","text":""},{"location":"changelog/#refactor_3","title":"Refactor","text":""},{"location":"changelog/#v0518-2024-11-06","title":"v0.5.18 (2024-11-06)","text":""},{"location":"changelog/#v0517-2024-11-05","title":"v0.5.17 (2024-11-05)","text":""},{"location":"changelog/#feat_5","title":"Feat","text":""},{"location":"changelog/#fix_3","title":"Fix","text":""},{"location":"changelog/#refactor_4","title":"Refactor","text":""},{"location":"changelog/#v0516-2024-10-21","title":"v0.5.16 (2024-10-21)","text":""},{"location":"changelog/#v0515-2024-10-21","title":"v0.5.15 (2024-10-21)","text":""},{"location":"changelog/#v0514-2024-10-21","title":"v0.5.14 (2024-10-21)","text":""},{"location":"changelog/#refactor_5","title":"Refactor","text":""},{"location":"changelog/#v0513-2024-10-21","title":"v0.5.13 (2024-10-21)","text":""},{"location":"changelog/#feat_6","title":"Feat","text":""},{"location":"changelog/#refactor_6","title":"Refactor","text":""},{"location":"changelog/#v0512-2024-10-18","title":"v0.5.12 (2024-10-18)","text":""},{"location":"changelog/#feat_7","title":"Feat","text":""},{"location":"changelog/#fix_4","title":"Fix","text":""},{"location":"changelog/#refactor_7","title":"Refactor","text":""},{"location":"changelog/#v0511-2024-10-10","title":"v0.5.11 (2024-10-10)","text":""},{"location":"changelog/#feat_8","title":"Feat","text":""},{"location":"changelog/#fix_5","title":"Fix","text":""},{"location":"changelog/#refactor_8","title":"Refactor","text":""},{"location":"changelog/#v0510-2024-10-07","title":"v0.5.10 (2024-10-07)","text":""},{"location":"changelog/#feat_9","title":"Feat","text":""},{"location":"changelog/#v059-2024-10-06","title":"v0.5.9 (2024-10-06)","text":""},{"location":"changelog/#feat_10","title":"Feat","text":""},{"location":"changelog/#fix_6","title":"Fix","text":""},{"location":"changelog/#v058-2024-10-04","title":"v0.5.8 (2024-10-04)","text":""},{"location":"changelog/#refactor_9","title":"Refactor","text":""},{"location":"changelog/#v057-2024-10-04","title":"v0.5.7 (2024-10-04)","text":""},{"location":"changelog/#feat_11","title":"Feat","text":""},{"location":"changelog/#refactor_10","title":"Refactor","text":""},{"location":"changelog/#v056-2024-10-03","title":"v0.5.6 (2024-10-03)","text":""},{"location":"changelog/#feat_12","title":"Feat","text":""},{"location":"changelog/#v055-2024-10-03","title":"v0.5.5 (2024-10-03)","text":""},{"location":"changelog/#feat_13","title":"Feat","text":""},{"location":"changelog/#refactor_11","title":"Refactor","text":""},{"location":"changelog/#v054-2024-10-02","title":"v0.5.4 (2024-10-02)","text":""},{"location":"changelog/#v053-2024-10-02","title":"v0.5.3 (2024-10-02)","text":""},{"location":"changelog/#fix_7","title":"Fix","text":""},{"location":"changelog/#v052-2024-10-02","title":"v0.5.2 (2024-10-02)","text":""},{"location":"changelog/#feat_14","title":"Feat","text":""},{"location":"changelog/#refactor_12","title":"Refactor","text":""},{"location":"changelog/#v051-2024-10-02","title":"v0.5.1 (2024-10-02)","text":""},{"location":"changelog/#refactor_13","title":"Refactor","text":""},{"location":"changelog/#v050-2024-10-02","title":"v0.5.0 (2024-10-02)","text":""},{"location":"changelog/#feat_15","title":"Feat","text":""},{"location":"changelog/#v045-2024-10-02","title":"v0.4.5 (2024-10-02)","text":""},{"location":"changelog/#fix_8","title":"Fix","text":""},{"location":"changelog/#v044-2024-10-02","title":"v0.4.4 (2024-10-02)","text":""},{"location":"changelog/#v043-2024-10-02","title":"v0.4.3 (2024-10-02)","text":""},{"location":"changelog/#feat_16","title":"Feat","text":""},{"location":"changelog/#fix_9","title":"Fix","text":""},{"location":"changelog/#refactor_14","title":"Refactor","text":""},{"location":"changelog/#v042-2024-10-01","title":"v0.4.2 (2024-10-01)","text":""},{"location":"changelog/#refactor_15","title":"Refactor","text":""},{"location":"changelog/#v041-2024-10-01","title":"v0.4.1 (2024-10-01)","text":""},{"location":"changelog/#feat_17","title":"Feat","text":""},{"location":"changelog/#fix_10","title":"Fix","text":""},{"location":"changelog/#refactor_16","title":"Refactor","text":""},{"location":"changelog/#v040-2024-09-30","title":"v0.4.0 (2024-09-30)","text":""},{"location":"changelog/#feat_18","title":"Feat","text":""},{"location":"changelog/#fix_11","title":"Fix","text":""},{"location":"changelog/#refactor_17","title":"Refactor","text":""},{"location":"changelog/#v031-2024-09-29","title":"v0.3.1 (2024-09-29)","text":""},{"location":"changelog/#refactor_18","title":"Refactor","text":""},{"location":"changelog/#v030-2024-09-29","title":"v0.3.0 (2024-09-29)","text":""},{"location":"changelog/#feat_19","title":"Feat","text":""},{"location":"changelog/#fix_12","title":"Fix","text":""},{"location":"changelog/#refactor_19","title":"Refactor","text":""},{"location":"changelog/#v020-2024-09-29","title":"v0.2.0 (2024-09-29)","text":""},{"location":"changelog/#feat_20","title":"Feat","text":""},{"location":"changelog/#fix_13","title":"Fix","text":""},{"location":"changelog/#refactor_20","title":"Refactor","text":""},{"location":"concepts/Chain-Modules/","title":"Chain Modules","text":""},{"location":"concepts/Chain-Modules/#xdid-auth-authz","title":"x/did - Auth & AuthZ","text":"

The DID module is responsible for managing the creation and management of DIDs. Controllers represent on-chain accounts backed by a MPC keypair. Controllers provide methods for Wallet Account Abstraction (WAA) and are responsible for managing the creation and management of DIDs for an individual user.

"},{"location":"concepts/Chain-Modules/#features","title":"Features","text":""},{"location":"concepts/Chain-Modules/#references","title":"References","text":""},{"location":"concepts/Chain-Modules/#xmacaroon","title":"x/macaroon","text":"

The macaroon module is responsible for issuing and verifying macaroons. Macaroons are used to authenticate and authorize requests between services. Macaroons are requested by NFT Records from x/service and granted by controllers from x/did

"},{"location":"concepts/Chain-Modules/#features_1","title":"Features","text":""},{"location":"concepts/Chain-Modules/#references_1","title":"References","text":""},{"location":"concepts/Chain-Modules/#xservice","title":"x/service","text":"

The service module is responsible for managing decentralized services. Services on the Sonr network are essentially on-chain MultiSig wallets that are represented by a NFT. Service admins are represented by a x/did controller and are required to state the service's scope of access, and which map to the services' capabilities.

"},{"location":"concepts/Chain-Modules/#features_2","title":"Features","text":""},{"location":"concepts/Chain-Modules/#references_2","title":"References","text":""},{"location":"concepts/Chain-Modules/#xvault","title":"x/vault","text":"

The vault module is responsible for managing the storage and acccess-control of Decentralized Web Nodes (DWNs) from IPFS. Vaults contain user-facing keys and are represented by a x/did controller.

"},{"location":"concepts/Chain-Modules/#features_3","title":"Features","text":""},{"location":"concepts/Chain-Modules/#references_3","title":"References","text":""},{"location":"concepts/Consumer-Launch/","title":"Consumer Chain Launch Process","text":"

This guide is intended for consumer chain teams that are looking to be onboarded on to the Interchain Security testnet.

"},{"location":"concepts/Consumer-Launch/#interchain-security-testnet-overview","title":"Interchain Security Testnet Overview","text":""},{"location":"concepts/Consumer-Launch/#chain-onboarding-process","title":"Chain Onboarding Process","text":"

For teams looking to join the ICS testnet, the onboarding process can be broken down in four phases:

"},{"location":"concepts/Consumer-Launch/#local-testing-and-integration","title":"Local Testing and Integration","text":"

During this phase, your team will run integration tests with the following elements of an Interchain Security testnet:

By the end of this phase, you are able to launch a consumer chain within a local testnet or CI workflow that resembles the testnet (or mainnet) environment.

"},{"location":"concepts/Consumer-Launch/#planning-with-testnet-coordinators","title":"Planning with Testnet Coordinators","text":"

Once you have a binary release ready, you can begin planning the launch with the testnet coordinators (Hypha).

The goals of this phase are to update this repository with all the information validators need to join the network and to produce a consumer-addition proposal to be submitted in the provider chain.

We expect you to run the minimum infrastructure required to make your consumer chain usable by testnet participants. This means running:

  1. Seed/persistent nodes
  2. Relayer it must be launched before the chain times out, preferably right after blocks start being produced.
  3. IMPORTANT: Make sure you have funds to pay gas fees for the relayer. You will likely need to set up an adequately funded genesis account for this purpose.

Additionally, you may want to run:

"},{"location":"concepts/Consumer-Launch/#submitting-a-pr-for-a-new-chain","title":"\u270d\ufe0f Submitting a PR for a new chain","text":"

Each consumer chain gets its own directory. You can use the slasher chain as reference. Feel free to clone the slasher directory, modify it for your consumer chain, and make a PR with the relevant information.

Hypha will be reviewing the PR to ensure it meets the following criteria:

"},{"location":"concepts/Consumer-Launch/#readme-includes","title":"README includes:","text":"

See the slasher chain page for reference.

"},{"location":"concepts/Consumer-Launch/#chain_id-must-be-identical-in-the-following-places","title":"chain_id must be identical in the following places:","text":"

We recommend choosing a chain_id with the suffix -1, even if it's a subsequent test of the same chain, e.g. testchain-second-rehearsal-1.

"},{"location":"concepts/Consumer-Launch/#binary-checksum-validation","title":"Binary checksum validation","text":""},{"location":"concepts/Consumer-Launch/#bash-script","title":"Bash script","text":""},{"location":"concepts/Consumer-Launch/#genesis-file","title":"Genesis file","text":"

See the slasher chain genesis for reference.

"},{"location":"concepts/Consumer-Launch/#consumer-addition-proposal","title":"consumer-addition proposal","text":"

See the slasher chain consumer-addition proposal and Interchain Security time-based parameters for reference.

"},{"location":"concepts/Consumer-Launch/#node-configurations","title":"Node configurations","text":""},{"location":"concepts/Consumer-Launch/#on-chain-proposal-submission","title":"On-chain Proposal Submission","text":"

When you make your proposal, please let us know well in advance. The current voting period is five minutes, which means we\u2019ll need to vote right after you submit your proposal. We recommend submitting the proposal together with us on a call.

The following will take place during the proposal submission phase:

"},{"location":"concepts/Consumer-Launch/#chain-launch","title":"Chain Launch","text":"

After the spawn time is reached, the Cross-Chain Validation (CCV) state will be available on the provider chain and the new IBC client will be created. At this point, you will be able to:

The consumer chain will start producing blocks as soon as 66.67% of the provider chain's voting power comes online. You will be able to start the relayer afterwards:

Finally, the testnet coordinators will:

"},{"location":"concepts/Consumer-Launch/#talk-to-us","title":"Talk to us","text":"

If you're a consumer chain looking to launch, please get in touch with Hypha. You can reach Lexa Michaelides at lexa@hypha.coop or on Telegram.

"},{"location":"concepts/Self-Custody/","title":"Self Custody","text":"

With increasingly sensitive information being stored in centralized databases, we believe that a decentralized anonymity mechanism is the only way to protect user data. Sonr is at its core a peer-to-peer identity system, which means that users can choose to share their identity with others in a way that is private and secure.

"},{"location":"concepts/Self-Custody/#decentralized-identifiers","title":"Decentralized Identifiers","text":""},{"location":"concepts/Self-Custody/#cross-chain-interoperability","title":"Cross-chain Interoperability","text":""},{"location":"concepts/Self-Custody/#w3c-web-apis","title":"W3C Web APIs","text":""},{"location":"concepts/System-Architecture/","title":"System Architecture","text":"

Sonr is a decentralized platform that allows users to create and manage their own decentralized identity.

"},{"location":"concepts/System-Architecture/#blockchain-sonr","title":"Blockchain: Sonr","text":"

Sonr stores Decentralized Identifiers (DIDs) on its Cosmos-sdk based blockchain. The blockchain's role is to act as the persistent pointer store for locations of User owned data.

"},{"location":"concepts/System-Architecture/#user-key-vault-motr","title":"User Key Vault: Motr","text":"

The Motr node is a service-worker which functions as a personal encrypted key-enclave for users stored on IPFS. They can be allocated and persisted on the Sonr blockchain for Smart Wallet functionality.

"},{"location":"concepts/System-Architecture/#network-gateway-hway","title":"Network Gateway: Hway","text":"

The Hway protocol is a network proxy which routes network requests to the appropriate service endpoint. This is used for seamless communication between Blockchain Nodes, Decentralized Applications, and User Nodes.

"},{"location":"concepts/System-Architecture/#design-system-nebula","title":"Design System: Nebula","text":"

Built with Golang-Templ, TailwindCSS, HTMX, and Service Workers - Nebula is a component library which allows for consistent UX across the entire ecosystem.

"},{"location":"concepts/Token-Economy/","title":"Token Economy","text":"

The $SNR token is the native platform token of the Sonr network. It is used by services to pay for Authentication and Authorization services. The system is designed for developers to be similar to centralized authentication providers like Google, Facebook, Okta, etc.

"},{"location":"concepts/Token-Economy/#usage","title":"Usage","text":"

The Sonr blockchain is a Delegated Proof of Stake (DPoS) blockchain built with the Cosmos-sdk.

"},{"location":"concepts/Token-Economy/#supply","title":"Supply","text":"

The total supply of $SNR is fixed at 1 billion.

"},{"location":"concepts/ibc-accounts/","title":"Interchain Accounts","text":"

:::note Synopsis Learn about what the Interchain Accounts module is :::

"},{"location":"concepts/ibc-accounts/#what-is-the-interchain-accounts-module","title":"What is the Interchain Accounts module?","text":"

Interchain Accounts is the Cosmos SDK implementation of the ICS-27 protocol, which enables cross-chain account management built upon IBC.

Regular accounts use a private key to sign transactions. Interchain Accounts are instead controlled programmatically by counterparty chains via IBC packets.

"},{"location":"concepts/ibc-accounts/#concepts","title":"Concepts","text":"

Host Chain: The chain where the interchain account is registered. The host chain listens for IBC packets from a controller chain which should contain instructions (e.g. Cosmos SDK messages) for which the interchain account will execute.

Controller Chain: The chain registering and controlling an account on a host chain. The controller chain sends IBC packets to the host chain to control the account.

Interchain Account: An account on a host chain created using the ICS-27 protocol. An interchain account has all the capabilities of a normal account. However, rather than signing transactions with a private key, a controller chain will send IBC packets to the host chain which signals what transactions the interchain account should execute.

Authentication Module: A custom application module on the controller chain that uses the Interchain Accounts module to build custom logic for the creation & management of interchain accounts. It can be either an IBC application module using the legacy API, or a regular Cosmos SDK application module sending messages to the controller submodule's MsgServer (this is the recommended approach from ibc-go v6 if access to packet callbacks is not needed). Please note that the legacy API will eventually be removed and IBC applications will not be able to use them in later releases.

"},{"location":"concepts/ibc-accounts/#sdk-security-model","title":"SDK security model","text":"

SDK modules on a chain are assumed to be trustworthy. For example, there are no checks to prevent an untrustworthy module from accessing the bank keeper.

The implementation of ICS-27 in ibc-go uses this assumption in its security considerations.

The implementation assumes other IBC application modules will not bind to ports within the ICS-27 namespace.

"},{"location":"concepts/ibc-accounts/#channel-closure","title":"Channel Closure","text":"

The provided interchain account host and controller implementations do not support ChanCloseInit. However, they do support ChanCloseConfirm. This means that the host and controller modules cannot close channels, but they will confirm channel closures initiated by other implementations of ICS-27.

In the event of a channel closing (due to a packet timeout in an ordered channel, for example), the interchain account associated with that channel can become accessible again if a new channel is created with a (JSON-formatted) version string that encodes the exact same Metadata information of the previous channel. The channel can be reopened using either MsgRegisterInterchainAccount or MsgChannelOpenInit. If MsgRegisterInterchainAccount is used, then it is possible to leave the version field of the message empty, since it will be filled in by the controller submodule. If MsgChannelOpenInit is used, then the version field must be provided with the correct JSON-encoded Metadata string. See section Understanding Active Channels for more information.

When reopening a channel with the default controller submodule, the ordering of the channel cannot be changed. In order to change the ordering of the channel, the channel has to go through a channel upgrade handshake or reopen the channel with a custom controller implementation.

"},{"location":"concepts/nebula-ui/","title":"Nebula ui","text":"

In order to maintain a tight-knit experience, we designed Sonr to operate completely in the point-of-view of the user. This led to us building a Component Library which creates consistent UX across the entire ecosystem.

"},{"location":"concepts/nebula-ui/#overview","title":"Overview","text":"

The Sonr blockchain is a Delegated Proof of Stake (DPoS) blockchain built with the Cosmos-sdk.

"},{"location":"concepts/nebula-ui/#nebula-package","title":"Nebula Package","text":"

The total supply of $SNR is fixed at 1 billion.

"},{"location":"concepts/sdk-usage/","title":"Sdk usage","text":""},{"location":"concepts/sdk-usage/#xdid-auth-authz","title":"x/did - Auth & AuthZ","text":"

The DID module is responsible for managing the creation and management of DIDs. Controllers represent on-chain accounts backed by a MPC keypair. Controllers provide methods for Wallet Account Abstraction (WAA) and are responsible for managing the creation and management of DIDs for an individual user.

"},{"location":"concepts/sdk-usage/#features","title":"Features","text":""},{"location":"concepts/sdk-usage/#references","title":"References","text":""},{"location":"concepts/sdk-usage/#xmacaroon","title":"x/macaroon","text":"

The macaroon module is responsible for issuing and verifying macaroons. Macaroons are used to authenticate and authorize requests between services. Macaroons are requested by NFT Records from x/service and granted by controllers from x/did

"},{"location":"concepts/sdk-usage/#features_1","title":"Features","text":""},{"location":"concepts/sdk-usage/#references_1","title":"References","text":""},{"location":"concepts/sdk-usage/#xservice","title":"x/service","text":"

The service module is responsible for managing decentralized services. Services on the Sonr network are essentially on-chain MultiSig wallets that are represented by a NFT. Service admins are represented by a x/did controller and are required to state the service's scope of access, and which map to the services' capabilities.

"},{"location":"concepts/sdk-usage/#features_2","title":"Features","text":""},{"location":"concepts/sdk-usage/#references_2","title":"References","text":""},{"location":"concepts/sdk-usage/#xvault","title":"x/vault","text":"

The vault module is responsible for managing the storage and acccess-control of Decentralized Web Nodes (DWNs) from IPFS. Vaults contain user-facing keys and are represented by a x/did controller.

"},{"location":"concepts/sdk-usage/#features_3","title":"Features","text":""},{"location":"concepts/sdk-usage/#references_3","title":"References","text":""},{"location":"concepts/svc-management/","title":"Svc management","text":"

The $SNR token is the native platform token of the Sonr network. It is used by services to pay for Authentication and Authorization services. The system is designed for developers to be similar to centralized authentication providers like Google, Facebook, Okta, etc.

"},{"location":"concepts/svc-management/#usage","title":"Usage","text":"

The Sonr blockchain is a Delegated Proof of Stake (DPoS) blockchain built with the Cosmos-sdk.

"},{"location":"concepts/svc-management/#supply","title":"Supply","text":"

The total supply of $SNR is fixed at 1 billion.

"},{"location":"foundations/","title":"Sonr Blockchain","text":""},{"location":"foundations/hway/","title":"Hway","text":"# Page Not Found ![A UFO takes one of the little worker monsters](/assets/images/undraw-taken.svg) The page you were looking for couldn't be found. Press [[/]] to search, or [head back to the homepage](/)."},{"location":"foundations/motr/","title":"Motr","text":"# Page Not Found ![A UFO takes one of the little worker monsters](/assets/images/undraw-taken.svg) The page you were looking for couldn't be found. Press [[/]] to search, or [head back to the homepage](/)."}]}