{"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.
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":"Meta
message from genesis.proto
DIDNamespace
to have proper naming conventionx/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":"x/accounts
std interface for WAA.x/did
controller and are required to state the controller's public key, and which map to the controller's capabilities.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
blockHeight
.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.
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.
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":"For teams looking to join the ICS testnet, the onboarding process can be broken down in four phases:
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:
Additionally, you may want to run:
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.
chain_id
must be identical in the following places:","text":"README
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
.
shasum -a 256 <binary>
matches the checksum in the proposalshasum -a 256 <binary>
matches README
README
README
consumer-addition
proposalREADME
signed_blocks_window
and min_signed_per_window
adequately to ensure validators have at least 12 hours to join the chain after launch without getting jailedshasum -a 256 <genesis file without CCV>
matches the checksum in the proposalshasum -a 256 <genesis file without CCV>
matches the checksum in the README
<consumer binary or gaiad> validate-genesis /path/to/genesis-without-ccv.json
returns without errorSee the slasher
chain genesis for reference.
consumer-addition
proposal","text":"revision_height: 1
revision_number: 1
(only if the chain_id
ends in -1
)transfer_timeout_period: 1800000000000
. This value should be smaller than blocks_per_distribution_transmission * block_time
.ccv_timeout_period: 2419200000000000
. This value must be larger than the unbonding period, the default is 28 days.unbonding_period: 1728000000000000
(given current provider params)See the slasher
chain consumer-addition proposal and Interchain Security time-based parameters for reference.
minimum_gas_prices
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:
consumer-addition
proposal with a command that looks like this: gaiad tx gov submit-legacy-proposal consumer-addition proposal.json --from <account name> --chain-id provider --gas auto --fees 500uatom -b block -y
announcements
channel of the Cosmos Network Discord Server. If you need permissions for posting, please reach out to us.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:
gaiad q provider consumer-genesis <chain-id> -o json > ccv-state.json
jq -s '.[0].app_state.ccvconsumer = .[1] | .[0]' <consumer genesis without CCV state> ccv-state.json > <consumer genesis file with CCV state>
interchain-security-testnet
channel of the Cosmos Network Discord Server.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:
gaiad q provider list-consumer-chains
hermes create connection --a-chain <consumer chain ID> --a-client 07-tendermint-0 --b-client <provider chain client ID> hermes create channel --a-chain <consumer chain ID> --a-port consumer --b-port provider --order ordered --a-connection connection-0 --channel-version 1
0.25
on the provider chain, so you should use a trusting period of 5 days in your relayer configuration.Finally, the testnet coordinators will:
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.
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.
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.
:::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.
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.
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":"x/accounts
std interface for WAA.x/did
controller and are required to state the controller's public key, and which map to the controller's capabilities.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
blockHeight
.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.
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.
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.
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.