mirror of
https://github.com/sonr-io/sonr.git
synced 2026-08-02 17:31:39 +00:00
Prad Nukala
@@ -0,0 +1,305 @@
|
||||
---
|
||||
title: Distribution
|
||||
description: SNR token distribution model, allocation strategy, and economic distribution mechanisms
|
||||
sidebarTitle: "Supply & Distribution"
|
||||
icon: "chart-pie"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
The SNR token distribution is designed to balance immediate network needs with long-term sustainability, ensuring fair allocation across stakeholders while maintaining sufficient reserves for ecosystem growth.
|
||||
|
||||
**Total Supply: 1,000,000,000 SNR**
|
||||
|
||||
<Note>
|
||||
Token distribution follows a carefully planned vesting schedule to prevent
|
||||
market manipulation and ensure aligned incentives across all participants.
|
||||
</Note>
|
||||
|
||||
## Supply Dynamics
|
||||
|
||||
### Circulating Supply Factors
|
||||
|
||||
The circulating token supply depends on several key factors:
|
||||
|
||||
<CardGroup>
|
||||
<Card title="Initial Circulation">
|
||||
200M SNR at genesis (20% of total supply)
|
||||
</Card>
|
||||
<Card title="Minted Tokens">
|
||||
New tokens created through inflation for rewards and subsidies
|
||||
</Card>
|
||||
<Card title="Vesting Releases">
|
||||
Scheduled releases from locked allocations over time
|
||||
</Card>
|
||||
<Card title="Staked Tokens">
|
||||
Tokens locked in staking reducing effective circulation
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
### Token Velocity
|
||||
|
||||
Token velocity measures how frequently tokens change hands and directly impacts token value:
|
||||
|
||||
```math
|
||||
\text{Token Value} = \frac{\text{Economic Activity}}{\text{Circulating Supply} \times \text{Velocity}}
|
||||
```
|
||||
|
||||
## Allocation Strategy
|
||||
|
||||
### Core Allocations
|
||||
|
||||
The token distribution prioritizes long-term network health through strategic allocations:
|
||||
|
||||
1. **Community & Ecosystem** (35% - 350M SNR)
|
||||
- Airdrop Program: 100M SNR (10%)
|
||||
- Testnet Incentives: 50M SNR (5%)
|
||||
- Staking Rewards Pool: 100M SNR (10%)
|
||||
- Ecosystem Grants: 100M SNR (10%)
|
||||
|
||||
2. **Team & Advisors** (20% - 200M SNR)
|
||||
- Team Allocation: 150M SNR (15%)
|
||||
- Advisors: 50M SNR (5%)
|
||||
|
||||
3. **Investors** (25% - 250M SNR)
|
||||
- Seed Round: 75M SNR (7.5%)
|
||||
- Series A: 100M SNR (10%)
|
||||
- Strategic Round: 75M SNR (7.5%)
|
||||
|
||||
4. **Foundation Treasury** (15% - 150M SNR)
|
||||
- Operations: 75M SNR (7.5%)
|
||||
- Reserve Fund: 75M SNR (7.5%)
|
||||
|
||||
5. **Validator Incentives** (5% - 50M SNR)
|
||||
- Genesis Validators: 30M SNR (3%)
|
||||
- Delegation Program: 20M SNR (2%)
|
||||
|
||||
### Vesting Schedules
|
||||
|
||||
<Warning>
|
||||
All non-circulating allocations follow strict vesting schedules to ensure
|
||||
gradual market entry and prevent supply shocks.
|
||||
</Warning>
|
||||
|
||||
#### Team Vesting
|
||||
|
||||
- **Team**: 12-month cliff, 48-month linear vest
|
||||
- **Advisors**: 6-month cliff, 24-month linear vest
|
||||
- No transfers until cliff periods expire
|
||||
|
||||
#### Investor Vesting
|
||||
|
||||
- **Seed Round**: 6-month cliff, 36-month linear vest
|
||||
- **Series A**: 3-month cliff, 24-month linear vest
|
||||
- **Strategic Round**: 25% immediate, remainder over 18 months
|
||||
|
||||
#### Community Vesting
|
||||
|
||||
- **Airdrop**: 25% immediate, 75% over 12 months
|
||||
- **Testnet**: Distribution over 6-month testnet period
|
||||
- **Ecosystem Grants**: Project milestone-based releases
|
||||
|
||||
#### Foundation Vesting
|
||||
|
||||
- **Operations**: 10% at genesis, 90% over 5 years
|
||||
- **Reserve Fund**: Minimum 3 years lockup, governance approval required
|
||||
|
||||
## Inflation Mechanism
|
||||
|
||||
### Reward Distribution
|
||||
|
||||
The network implements controlled inflation to incentivize participation:
|
||||
|
||||
<CardGroup>
|
||||
<Card title="Validator Rewards">
|
||||
Block rewards for consensus participation distributed pro-rata to stake
|
||||
</Card>
|
||||
<Card title="Highway Services">
|
||||
Compensation for off-chain computation, storage, and routing services
|
||||
</Card>
|
||||
<Card title="Governance Rewards">
|
||||
Incentives for proposal creation and voting participation
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
### Inflation Schedule
|
||||
|
||||
**Year 1**: 15% inflation (aggressive growth)
|
||||
- Focus on network bootstrapping
|
||||
- High rewards for early adopters
|
||||
|
||||
**Year 2**: 12% inflation (continued expansion)
|
||||
- Stabilization period begins
|
||||
- Balanced growth incentives
|
||||
|
||||
**Year 3**: 9% inflation (stabilization)
|
||||
- Network maturation
|
||||
- Sustainable reward levels
|
||||
|
||||
**Year 4+**: 7% inflation (long-term sustainability)
|
||||
- Minimal dilution
|
||||
- Self-sustaining economics
|
||||
|
||||
## Economic Safeguards
|
||||
|
||||
### Anti-Manipulation Measures
|
||||
|
||||
1. **Vesting Cliffs**: Prevent immediate dumps from large holders
|
||||
2. **Staking Lockups**: Reduce liquid supply through validator requirements
|
||||
3. **Governance Delays**: Time-locked treasury withdrawals
|
||||
4. **Slashing Penalties**: Discourage malicious validator behavior
|
||||
|
||||
### Supply Controls
|
||||
|
||||
The network implements several mechanisms to manage token supply:
|
||||
|
||||
- **Fee Burning**: 50% of transaction fees burned (deflationary)
|
||||
- **Treasury Management**: Governance-controlled minting caps
|
||||
- **Dynamic Rewards**: Adjustment based on network participation
|
||||
- **Lock Incentives**: Higher rewards for longer staking periods
|
||||
|
||||
### Centralization Risks
|
||||
|
||||
- No single entity controls >20% at genesis
|
||||
- Team tokens have longest vesting (4 years)
|
||||
- Foundation treasury requires governance approval
|
||||
- Validator set caps prevent concentration
|
||||
|
||||
### Market Stability
|
||||
|
||||
- Staggered vesting prevents supply shocks
|
||||
- Fee burning provides deflationary pressure
|
||||
- Utility demand from identity services
|
||||
- Cross-chain value capture mechanisms
|
||||
|
||||
## Token Utility & Value Accrual
|
||||
|
||||
### Primary Utilities
|
||||
|
||||
<CardGroup>
|
||||
<Card title="Network Security">
|
||||
Staking for validation and delegation
|
||||
</Card>
|
||||
<Card title="Governance">
|
||||
Voting on protocol upgrades and parameters
|
||||
</Card>
|
||||
<Card title="Transaction Fees">
|
||||
Gas payments for network operations
|
||||
</Card>
|
||||
<Card title="Identity Services">
|
||||
Premium features and API access
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
### Value Accrual Mechanisms
|
||||
|
||||
1. **Fee Burning**: 50% of transaction fees burned (deflationary)
|
||||
2. **Staking Yield**: 7-15% APR depending on network participation
|
||||
3. **Identity Revenue**: Enterprise licensing fees distributed to stakers
|
||||
4. **Cross-chain Value**: IBC transfer fees and bridge operations
|
||||
|
||||
### Staking Targets
|
||||
|
||||
- **Target staking ratio**: 65%
|
||||
- **Validator set**: 50-100 active validators
|
||||
- **Minimum stake**: 1M SNR (0.1% of supply)
|
||||
- **Delegation minimum**: 1 SNR (accessible to all)
|
||||
|
||||
### Vesting Schedule Overview
|
||||
|
||||
| Category | Immediate | 6 Months | 12 Months | 24 Months | 36 Months | 48 Months |
|
||||
|----------|-----------|----------|-----------|-----------|-----------|-----------|
|
||||
| Airdrop | 25% | 50% | 75% | 100% | - | - |
|
||||
| Team | 0% | 0% | 12.5% | 37.5% | 62.5% | 100% |
|
||||
| Seed Investors | 0% | 0% | 16.7% | 50% | 83.3% | 100% |
|
||||
| Series A | 0% | 25% | 50% | 100% | - | - |
|
||||
| Foundation | 10% | 28% | 46% | 64% | 82% | 100% |
|
||||
|
||||
<Check>
|
||||
The distribution model prioritizes network security, ecosystem growth, and
|
||||
fair participant rewards while maintaining economic sustainability.
|
||||
</Check>
|
||||
|
||||
## Distribution Timeline
|
||||
|
||||
### Pre-Launch (Months -6 to 0)
|
||||
|
||||
- Team allocation locked
|
||||
- Investor funds raised
|
||||
- Testnet incentives distributed
|
||||
- Airdrop snapshot taken
|
||||
|
||||
### Genesis (Month 0)
|
||||
|
||||
- 200M SNR circulating supply
|
||||
- Genesis validators receive allocation
|
||||
- Foundation treasury initialized
|
||||
- Staking rewards begin
|
||||
|
||||
### Year 1 (Months 1-12)
|
||||
|
||||
- Airdrop vesting releases 75M SNR
|
||||
- Team cliff expires, vesting begins
|
||||
- Series A completes vesting
|
||||
- Ecosystem grants distributed
|
||||
|
||||
### Year 2-3 (Months 13-36)
|
||||
|
||||
- Seed round completes vesting
|
||||
- Team reaches 62.5% vested
|
||||
- Foundation operations fully unlocked
|
||||
- Validator program matured
|
||||
|
||||
## Economic Incentives
|
||||
|
||||
### Genesis Validator Program
|
||||
|
||||
- **Genesis Validators**: 30M SNR (3%)
|
||||
- 50 validators × 600,000 SNR each
|
||||
- 24 months minimum staking lockup
|
||||
- 99%+ uptime and governance participation required
|
||||
|
||||
### Delegation Program
|
||||
|
||||
- **Foundation Delegations**: 20M SNR (2%)
|
||||
- 6-month renewable terms
|
||||
- Performance-based allocation
|
||||
- Support for high-performing validators
|
||||
|
||||
### Maturity Phase (Year 3+)
|
||||
|
||||
- Stabilized inflation rate
|
||||
- Self-sustaining economics
|
||||
- Community-driven allocation
|
||||
|
||||
## Success Metrics
|
||||
|
||||
### Year 1 Targets
|
||||
|
||||
- 50% of supply staked
|
||||
- 50+ active validators
|
||||
- 100k+ active addresses
|
||||
- $10M+ in identity service revenue
|
||||
|
||||
### Year 3 Targets
|
||||
|
||||
- 65% of supply staked
|
||||
- 75+ active validators
|
||||
- 1M+ active addresses
|
||||
- $100M+ total value locked
|
||||
|
||||
### Long-term Vision (5+ years)
|
||||
|
||||
- Self-sustaining network economics
|
||||
- Deflationary token model
|
||||
- Industry-standard identity infrastructure
|
||||
- Billion-dollar ecosystem value
|
||||
|
||||
## Transparency Commitments
|
||||
|
||||
All token distributions are:
|
||||
|
||||
- Publicly verifiable on-chain
|
||||
- Subject to regular audits
|
||||
- Reported in quarterly updates
|
||||
- Governed by smart contracts
|
||||
@@ -0,0 +1,98 @@
|
||||
---
|
||||
title: "Governance"
|
||||
sidebarTitle: "Protocol Governance"
|
||||
description: "Governance is the process of making decisions on behalf of a group of people or organization"
|
||||
icon: "landmark"
|
||||
---
|
||||
|
||||
The Demand is rooted from participation in the governance process, determining upgrades to the protocol or allocation of resources, and supply is the result of the tokens eligible to participate in the governance process.
|
||||
On Sonr we will be leveraging a **delegate stake** mechanism in order to **optimize buy-in** for users in the network. It imposes an **excess opportunity cost** if **slashing** is implemented.
|
||||
|
||||
**Seven elements of economic design for governance**
|
||||
|
||||
1. Scope of Decisions
|
||||
2. Stakeholders
|
||||
3. Policy Research & Development
|
||||
4. Proposal Process
|
||||
5. Information Distribution Systems
|
||||
6. Decision Making Procedures
|
||||
7. Implementation & Property Rights
|
||||
|
||||
## Yearly Governance Cycle
|
||||
|
||||
- Two General Elections for proposals yearly
|
||||
- Proposals need at least 20% of all validator approval to move into general election
|
||||
- 51% of General Vote required for proposal to pass
|
||||
- Emergency Voting sessions can be called if requested by 51% of Governance Participants
|
||||
|
||||
### ☀️ Summer Cycle
|
||||
|
||||
| | Start Date | End Date |
|
||||
| ----------------------------- | ---------- | -------- |
|
||||
| Validator Vetting | 5/17 | 5/31 |
|
||||
| Proposals Posted | 6/1 | |
|
||||
| General Election of Proposals | 6/2 | 6/15 |
|
||||
| Results Posted | 6/16 | |
|
||||
|
||||
### ❄️ Winter Cycle
|
||||
|
||||
| | Start Date | End Date |
|
||||
| ----------------------------- | ---------- | -------- |
|
||||
| Validator Vetting | 11/17 | 11/31 |
|
||||
| Proposals Posted | 12/1 | |
|
||||
| General Election of Proposals | 12/2 | 12/15 |
|
||||
| Results Posted | 12/16 | |
|
||||
|
||||
## First Rollout Phase
|
||||
|
||||
These are the measures the core Sonr team will be undertaking prior and during test-net deployment.
|
||||
|
||||
### Establish Community
|
||||
|
||||
Build a loyal community of token holders that represent our platforms stakeholder groups.
|
||||
|
||||
- All of our existing token holders (this includes our founder and early investors) will be staking their Sonr Token in order to be incentivized to hold tokens and participate in voting
|
||||
- We will be actively networking with DeFi projects, blockchain service providers, and etc. in order to participate
|
||||
|
||||
### Build Dashboards
|
||||
|
||||
We are under the process of creating a [dashboard](https://sonrscan.io) in order to provide key metrics to our stakeholders
|
||||
|
||||
- **Technology**: Pricing, total fees paid, total storage used, uptime
|
||||
- **Governance**: Identities, proposal outcomes, community participation
|
||||
|
||||
### Polling System
|
||||
|
||||
Our initial polling system will be token weighted and not enforceable, in order to build engagement.
|
||||
|
||||
- Users will submit qualitative updates to the system and have them up/downvoted
|
||||
- The core team will then assess the submissions and select viable community suggestions into upgrades
|
||||
- Along side this, our team will locate and commission the development of a proposal for any technical upgrades without enforceable code proposals
|
||||
- We will be able to provide clarity, external security, and in applicable cases the economic evaluation from the impacts of proposals to the community.
|
||||
|
||||
## Second Rollout Phase
|
||||
|
||||
Phase 2 will be underway in the months prior to main-net deployment, along with an extensive security audit.
|
||||
|
||||
### On-Chain Execution
|
||||
|
||||
We will be introducing an on-chain, executable code-based governance system in stages with majority rule voting.
|
||||
|
||||
**Stage 1:** Grants Program
|
||||
|
||||
- Incorporate community voting for grant recipient selection
|
||||
- Allow users to submit proposals for grant allocation
|
||||
|
||||
**Stage 2:** Subsidies and Rewards
|
||||
|
||||
- Proposals to update subsidies and rewards can be submitted by Core Sonr Team or third parties
|
||||
- Core Team will be responsible for considering funding security, and economic audits for proposals
|
||||
|
||||
**Stage 3:** Technical Upgrades
|
||||
|
||||
- These include pricing, security, and bug fixes
|
||||
- Proposals will be spearheaded by the Sonr Team and/or its delegates
|
||||
|
||||
### Maintenance
|
||||
|
||||
When on-chain governance has come to fruition, the core Sonr team will be also maintaining the polling-based system with subsidized development to minimize barrier to entry. This will be incorporating governance within the Motor Nebula Widget itself.
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "Rewards"
|
||||
sidebarTitle: "Network Rewards"
|
||||
description: "Incentivizing the Sonr Ecosystem"
|
||||
icon: "gem"
|
||||
---
|
||||
|
||||
In order to maximize buy-in and network availability for the Sonr ecosystem, we will be implementing an empirical Token Rewards mechanism. Rewards are a way to create inflation in order to dilute the token value, resulting in an affordable onboarding and operational experience for the end user. The goal behind Sonr Token rewards is to subsidize Highway based computation, in order to promote value creation and platform growth.
|
||||
|
||||
### Governance Participation
|
||||
|
||||
At the time of Main-net launch, phase one of the Sonr governance rollout will be implemented and will result in a set of rewards for participants.
|
||||
|
||||
**Submission of Proposals**
|
||||
|
||||
Users will be incentivized to submit blockchain improvement or grant proposals to be reviewed by voting participants. In order to prevent game from low quality and out of scope proposals, a clear-cut submission and evaluation process will be put into place on a public facing FAQ website.
|
||||
|
||||
- Proposers are required to stake before submission — _“Application Fee”_
|
||||
|
||||
**Proposal Voting**
|
||||
|
||||
In order to prevent innovation from halting on the Sonr ecosystem, we incentivize all staked users to participate in the polling process for community submitted proposals. Users are then rewarded for good-faith participation in voting, while also sustaining momentum.
|
||||
|
||||
- Existing Stakeholders are rewarded for good-faith participation in voting
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: "Staking"
|
||||
sidebarTitle: "Staking Functions"
|
||||
description: "Understand the staking mechanism on Sonr"
|
||||
icon: "vault"
|
||||
---
|
||||
|
||||
The clear path for the underlying application for staking is utilizing a Delegated Proof of Stake (DPoS) validation mechanism. Down the line Sonr will provide IPFS storage nodes, and governance participation in the staking model.
|
||||
|
||||
<Tip>
|
||||
Demand = Obtain rewards, goods, or services through staking or locking up the token.
|
||||
Supply = Tokens staked or locked up.
|
||||
|
||||
</Tip>
|
||||
|
||||
On Sonr we will be leveraging a **delegate stake** mechanism in order to **optimize buy-in** for users in the network. It imposes an **excess opportunity cost** if **slashing** is implemented.
|
||||
|
||||
With this being said, there are some challenges in implementing staking:
|
||||
|
||||
- The token must already have value
|
||||
- Allocating power or influence via staking gives major edge to wealthy users
|
||||
- They are frequently subject to gaming and coordination problems
|
||||
|
||||
However there is substantial benefit in incorporating a staking mechanism, with the following criteria met we can create a sustainable design:
|
||||
|
||||
1. The upfront capital required to stake should not significantly discourage them to stake
|
||||
2. If a stakeholder group is making decisions that materially harm the network, they would be punished via slashing the stake.
|
||||
3. Stakeholders can make decisions that positively impact the future network health and token price, therefore holding stake can promote positive Sonr growth
|
||||
|
||||
### Validator Nodes for Cosmos ASB
|
||||
|
||||
Sonr is a Cosmos powered blockchain which is powered by a TenderMint validation mechanism. The default consensus for TenderMint is DPoS and works with our current ABCI implementation for Transaction Verification. DPoS is a twist on Proof of Stake consensus that relies upon a group of delegates to validate blocks on behalf of all nodes in the network . Witnesses are elected by stakeholders at a rate of one vote per share per witness . Coin age is irrelevant. All coins that are mature will add the same staking weight (usually 1 in the wallet hover display) Results in stable, consistent interest only for active wallets and only with small inputs.
|
||||
|
||||
### IPFS Storage Nodes (excluding FileCoin)
|
||||
|
||||
When deploying standalone highway nodes, requiring minimum stake would be an additional method to enforce availability requirements. By having a stake we can ensure that the user deploying a node has a base level of buy-in within the ecosystem.
|
||||
|
||||
### Governance Participants
|
||||
|
||||
We will be incorporating a similar strategy to AlgoRand in our governance rollout. This is covered more extensively in the [Governance](https://www.notion.so/Governance-af1251b1b7aa41fab16c53dd9fe6ef63) section.
|
||||
@@ -0,0 +1,201 @@
|
||||
---
|
||||
title: Utility
|
||||
description: Use cases and utility functions of the SNR token including staking, governance, and network operations
|
||||
sidebarTitle: "Network Utility"
|
||||
icon: "cog"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
The SNR token serves as the native utility token of the Sonr network, enabling various functions from transaction processing to governance participation. Its multi-faceted utility design ensures sustained demand and value accrual.
|
||||
|
||||
<Note>
|
||||
The SNR token's utility is designed to grow with the network, adding new use
|
||||
cases as the ecosystem expands while maintaining core functions for network
|
||||
security and operations.
|
||||
</Note>
|
||||
|
||||
## Core Utilities
|
||||
|
||||
### 1. Means of Payment
|
||||
|
||||
The primary utility of SNR is facilitating transactions across the Sonr blockchain for user account management and application operations.
|
||||
|
||||
<CardGroup>
|
||||
<Card title="Transaction Fees">
|
||||
All on-chain operations require SNR for gas fees and computational resources
|
||||
</Card>
|
||||
<Card title="Service Payments">
|
||||
Payment for Highway services, storage, and off-chain computation
|
||||
</Card>
|
||||
<Card title="Application Fees">
|
||||
Developers pay SNR to register and update applications on the network
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
### 2. Staking Mechanisms
|
||||
|
||||
SNR tokens enable network security and participation through various staking options:
|
||||
|
||||
#### Validator Staking
|
||||
|
||||
- **Minimum Stake**: Required SNR deposit to run a validator node
|
||||
- **Delegated Staking**: Users can delegate SNR to validators for rewards
|
||||
- **Slashing Protection**: Validators must maintain good behavior or risk stake loss
|
||||
|
||||
#### Service Node Staking
|
||||
|
||||
- **Highway Nodes**: Stake required for running Highway service nodes
|
||||
- **IPFS Storage**: Minimum stake for operating storage infrastructure
|
||||
- **Availability Guarantee**: Staking ensures node uptime and reliability
|
||||
|
||||
<Warning>
|
||||
Staking locks tokens for a specified period, reducing circulating supply while
|
||||
earning rewards for network participation.
|
||||
</Warning>
|
||||
|
||||
### 3. Governance Participation
|
||||
|
||||
SNR tokens grant voting power in the decentralized governance system:
|
||||
|
||||
<CardGroup>
|
||||
<Card title="Proposal Creation">
|
||||
Stake SNR to submit governance proposals with anti-spam mechanisms
|
||||
</Card>
|
||||
<Card title="Voting Rights">
|
||||
One token equals one vote in governance decisions
|
||||
</Card>
|
||||
<Card title="Participation Rewards">
|
||||
Earn SNR for active governance participation and quality proposals
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Module-Specific Operations
|
||||
|
||||
### Service Module (x/svc)
|
||||
|
||||
SNR tokens are required for service operations within the decentralized service marketplace:
|
||||
|
||||
- **Service Registration**: Pay SNR registration fees to claim unique TLD domains (e.g., `music.sonr`, `defi.sonr`)
|
||||
- **Capability Requests**: SNR deposits for requesting root capabilities via MPC signing
|
||||
- **Service Updates**: Fees for modifying service metadata or requesting additional permissions
|
||||
- **TLD Management**: Economic safeguards prevent domain squatting through registration fees
|
||||
|
||||
<Note>
|
||||
Service registration fees are burned or sent to the community pool based on
|
||||
governance parameters, creating deflationary pressure.
|
||||
</Note>
|
||||
|
||||
### DWN Module (x/dwn)
|
||||
|
||||
The DWN module enables revolutionary gasless onboarding while using SNR for advanced operations:
|
||||
|
||||
- **Gasless Vault Claiming**: Initial `MsgClaimVault` transactions require no SNR fees
|
||||
- **Vault Configuration**: SNR fees for updating vault settings and WASM runtime upgrades
|
||||
- **MPC Operations**: Transaction fees for multi-party computation within secure enclaves
|
||||
- **Cross-Chain Operations**: SNR payments for bridging assets and multi-chain vault management
|
||||
|
||||
### UCAN Module (x/ucan)
|
||||
|
||||
Authorization operations require SNR for security and spam prevention:
|
||||
|
||||
- **Root Capability Issuance**: SNR fees for initiating MPC threshold signing requests
|
||||
- **Revocation Processing**: Transaction fees for on-chain capability revocations
|
||||
- **Delegation Chain Verification**: Computational costs for validating complex authorization chains
|
||||
- **MPC Signing Participation**: Validator rewards for participating in multi-party computation
|
||||
|
||||
### DID Module (x/did)
|
||||
|
||||
Identity operations use SNR for registration and management:
|
||||
|
||||
- **DID Registration**: Fees for creating new decentralized identifiers
|
||||
- **Authentication Linking**: SNR costs for adding WebAuthn credentials or other auth methods
|
||||
- **Assertion Management**: Fees for linking/unlinking identity claims and verifications
|
||||
- **Transaction Execution**: SNR payments for UCAN-authorized transactions on behalf of DIDs
|
||||
|
||||
## Economic Mechanisms
|
||||
|
||||
### Demand Drivers
|
||||
|
||||
The token's value is driven by multiple demand sources:
|
||||
|
||||
```math
|
||||
\text{Demand} = \text{Transaction Volume} + \text{Staking Locked} + \text{Governance Participation}
|
||||
```
|
||||
|
||||
<CardGroup>
|
||||
<Card title="Network Growth">
|
||||
More users and applications increase transaction demand
|
||||
</Card>
|
||||
<Card title="Staking Returns">
|
||||
Attractive yields encourage long-term token locking
|
||||
</Card>
|
||||
<Card title="Utility Expansion">
|
||||
New features and services create additional use cases
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
### Supply Dynamics
|
||||
|
||||
Effective supply is reduced through:
|
||||
|
||||
- **Staking Lockups**: Validators and delegators lock tokens
|
||||
- **Governance Stakes**: Proposal creation requires token deposits
|
||||
- **Service Collateral**: Service providers stake SNR for TLD registration
|
||||
- **Fee Burns**: Partial fee burning reduces total supply
|
||||
|
||||
## Developer Incentives
|
||||
|
||||
### Service Development
|
||||
|
||||
- **Service Registration Subsidies**: Reduced TLD domain costs for verified developers
|
||||
- **Root Capability Grants**: Free MPC signing for approved service capabilities
|
||||
- **Revenue Sharing**: Earn portion of service interaction fees through UCAN delegation
|
||||
- **Integration Support**: Subsidized vault interaction costs for new services
|
||||
|
||||
### Infrastructure Provision
|
||||
|
||||
- **Validator Operations**: SNR staking rewards for consensus participation and MPC signing
|
||||
- **MPC Node Operations**: Additional rewards for multi-party computation services
|
||||
- **IPFS Storage**: Compensation for decentralized vault configuration storage
|
||||
- **UCAN Verification**: Fees for running delegation chain validation services
|
||||
|
||||
<Check>
|
||||
The SNR token creates a sustainable economic model where users, developers,
|
||||
and infrastructure providers all benefit from network growth.
|
||||
</Check>
|
||||
|
||||
## Future Utilities
|
||||
|
||||
### Enhanced Module Features
|
||||
|
||||
- **Advanced UCAN Features**: Zero-knowledge capability proofs and cross-chain validation
|
||||
- **Vault Upgrades**: Seamless WASM runtime updates and social recovery mechanisms
|
||||
- **Service Marketplace**: Categorized service discovery with reputation systems
|
||||
- **Multi-sig Services**: Shared service ownership through DAO governance
|
||||
|
||||
### Cross-Chain Integration
|
||||
|
||||
- **IBC UCAN Verification**: Cross-chain capability validation fees
|
||||
- **Multi-Chain Vault Operations**: Enhanced cross-chain asset management
|
||||
- **Bridge Service Registration**: Specialized TLD domains for bridge operators
|
||||
- **Interchain DID Resolution**: Cross-chain identity verification services
|
||||
|
||||
### Privacy and Security Enhancements
|
||||
|
||||
- **Privacy-Preserving MPC**: Enhanced secure multi-party computation features
|
||||
- **Conditional Revocations**: Time or event-based capability revocations
|
||||
- **Hardware Vault Support**: Integration with dedicated secure hardware
|
||||
- **AI-Powered Workflows**: Natural language vault command processing
|
||||
|
||||
## Utility Summary
|
||||
|
||||
The SNR token's utility encompasses:
|
||||
|
||||
1. **Essential Operations**: Core network functions and transactions
|
||||
2. **Security Provision**: Staking for network consensus and safety
|
||||
3. **Governance Rights**: Democratic participation in protocol decisions
|
||||
4. **Economic Incentives**: Rewards for valuable contributions
|
||||
5. **Access Control**: Gateway to premium features and services
|
||||
|
||||
This comprehensive utility design ensures the SNR token remains central to the Sonr ecosystem's growth and sustainability.
|
||||
@@ -0,0 +1,235 @@
|
||||
---
|
||||
title: Values
|
||||
description: Value proposition and economic principles underlying the SNR token and its role in the ecosystem
|
||||
sidebarTitle: "Core Values"
|
||||
icon: "heart"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
The SNR token's value derives from fundamental economic principles, network utility, and carefully designed tokenomics. Understanding these value drivers helps participants make informed decisions about their involvement in the Sonr ecosystem.
|
||||
|
||||
<Note>
|
||||
Token value = Fundamental Value + Token-Specific Non-Fundamentals +
|
||||
Market/Industry Non-Fundamentals
|
||||
</Note>
|
||||
|
||||
## Fundamental Value Drivers
|
||||
|
||||
### Economic Activity
|
||||
|
||||
The core value proposition stems from actual network usage across Sonr's core modules:
|
||||
|
||||
```math
|
||||
\text{Fundamental Value} = \frac{\text{Economic Activity}}{\text{Circulating Supply} \times \text{Velocity}}
|
||||
```
|
||||
|
||||
<CardGroup>
|
||||
<Card title="Service Registration">
|
||||
TLD domain fees and capability requests through the Service module
|
||||
</Card>
|
||||
<Card title="Identity Operations">
|
||||
DID registration, authentication linking, and assertion management
|
||||
</Card>
|
||||
<Card title="Authorization Services">
|
||||
UCAN issuance, revocation processing, and MPC signing operations
|
||||
</Card>
|
||||
<Card title="Vault Operations">
|
||||
DWN configuration updates and cross-chain management beyond gasless claiming
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
### Network Effects
|
||||
|
||||
Value increases exponentially with network growth:
|
||||
|
||||
1. **User Growth**: More vault claims and DID registrations increase identity network value
|
||||
2. **Service Adoption**: More TLD registrations create a valuable service namespace
|
||||
3. **Developer Integration**: Services leveraging UCAN authorization expand utility
|
||||
4. **Validator Participation**: MPC signing nodes improve security and capability issuance
|
||||
|
||||
## Property Rights
|
||||
|
||||
The SNR token grants specific rights that create intrinsic value:
|
||||
|
||||
### Governance Rights
|
||||
|
||||
- **Protocol Decisions**: Vote on network upgrades and parameters
|
||||
- **Treasury Management**: Control community fund allocation
|
||||
- **Economic Policy**: Influence inflation and reward distribution
|
||||
|
||||
### Economic Rights
|
||||
|
||||
- **Staking Rewards**: Earn returns for securing the network
|
||||
- **Fee Sharing**: Participate in protocol revenue distribution
|
||||
- **Priority Access**: Enhanced service levels for token holders
|
||||
|
||||
### Network Access
|
||||
|
||||
- **Service Registration**: Required for claiming TLD domains and registering services
|
||||
- **Identity Management**: Essential for DID operations and authentication linking
|
||||
- **Capability Authorization**: Needed for UCAN issuance and delegation chain verification
|
||||
- **Vault Configuration**: Access to advanced vault features beyond gasless claiming
|
||||
|
||||
<Check>
|
||||
The combination of governance, economic, and access rights creates a
|
||||
comprehensive value proposition for SNR holders.
|
||||
</Check>
|
||||
|
||||
## Value Accrual Mechanisms
|
||||
|
||||
### Supply Reduction
|
||||
|
||||
Multiple mechanisms reduce effective token supply:
|
||||
|
||||
<CardGroup>
|
||||
<Card title="Staking Lockups">
|
||||
Validators and delegators lock tokens for rewards
|
||||
</Card>
|
||||
<Card title="Fee Burning">
|
||||
Portion of transaction fees permanently removed
|
||||
</Card>
|
||||
<Card title="Governance Deposits">Tokens locked for proposal creation</Card>
|
||||
<Card title="Service Registration">
|
||||
TLD domain registration fees create deflationary pressure
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
### Demand Growth
|
||||
|
||||
Sustainable demand drivers include:
|
||||
|
||||
1. **Organic Growth**: Natural increase in users and transactions
|
||||
2. **New Use Cases**: Expanding utility through development
|
||||
3. **Partnership Integration**: External protocols adopting SNR
|
||||
4. **Premium Features**: Advanced services requiring SNR payment
|
||||
|
||||
## Economic Sustainability
|
||||
|
||||
### Revenue Model
|
||||
|
||||
The network generates sustainable revenue through module-specific operations:
|
||||
|
||||
- **Service Module**: TLD domain registration fees and capability request deposits
|
||||
- **DID Module**: Identity registration, authentication linking, and assertion management fees
|
||||
- **UCAN Module**: Root capability issuance and revocation processing fees
|
||||
- **DWN Module**: Advanced vault configuration and cross-chain operation fees
|
||||
- **Validator Operations**: MPC signing participation and consensus rewards
|
||||
|
||||
### Cost Structure
|
||||
|
||||
Efficient operations maintain profitability:
|
||||
|
||||
- **MPC Infrastructure**: Multi-party computation hardware and coordination costs
|
||||
- **Module Development**: Ongoing improvements to Service, DID, UCAN, and DWN modules
|
||||
- **Security Audits**: WASM runtime, capability verification, and cryptographic audits
|
||||
- **Gasless Subsidies**: Network-funded vault claiming to remove onboarding barriers
|
||||
|
||||
## Market Dynamics
|
||||
|
||||
### Price Discovery
|
||||
|
||||
Token price reflects multiple factors:
|
||||
|
||||
<Warning>
|
||||
While fundamental value provides a baseline, market sentiment and external
|
||||
factors significantly influence short-term price movements.
|
||||
</Warning>
|
||||
|
||||
### Non-Fundamental Factors
|
||||
|
||||
#### Token-Specific
|
||||
|
||||
- Marketing campaigns and viral growth
|
||||
- Exchange listings and liquidity
|
||||
- Partnership announcements
|
||||
- Technical milestones
|
||||
|
||||
#### Market-Wide
|
||||
|
||||
- Cryptocurrency market cycles
|
||||
- Regulatory developments
|
||||
- Macroeconomic conditions
|
||||
- Technology trends
|
||||
|
||||
## Value Propositions
|
||||
|
||||
### For Users
|
||||
|
||||
1. **Digital Sovereignty**: Control your DID and vault without intermediaries
|
||||
2. **Gasless Onboarding**: Free vault claiming removes barriers to entry
|
||||
3. **Seamless Authentication**: WebAuthn integration with hardware-backed security
|
||||
4. **UCAN Authorization**: Granular, revocable permissions replace dangerous unlimited approvals
|
||||
|
||||
### For Developers
|
||||
|
||||
1. **Service Registration**: Claim unique TLD domains for decentralized services
|
||||
2. **UCAN Integration**: Built-in authorization system with capability delegation
|
||||
3. **Identity Infrastructure**: Native DID support with WebAuthn authentication
|
||||
4. **Revenue Models**: Earn through UCAN-mediated service interactions and fee sharing
|
||||
|
||||
### For Validators
|
||||
|
||||
1. **MPC Signing Rewards**: Additional compensation for multi-party computation participation
|
||||
2. **Capability Issuance**: Central role in root UCAN creation through threshold signing
|
||||
3. **Network Security**: Staking rewards for consensus participation and vault protection
|
||||
4. **Governance Influence**: Vote on protocol parameters and module improvements
|
||||
|
||||
### For Investors
|
||||
|
||||
1. **Module Expansion**: Growing utility across Service, DID, UCAN, and DWN modules
|
||||
2. **Deflationary Pressure**: Service registration fees and transaction burns reduce supply
|
||||
3. **Identity Network Effects**: Value compounds as more DIDs and services join the ecosystem
|
||||
4. **Technical Innovation**: Cutting-edge MPC, WASM, and WebAuthn integration
|
||||
|
||||
## Comparative Advantages
|
||||
|
||||
### vs. Traditional Systems
|
||||
|
||||
- **No Intermediaries**: Direct value transfer
|
||||
- **Global Access**: Permissionless participation
|
||||
- **Transparency**: On-chain verification
|
||||
- **User Control**: Self-sovereign identity
|
||||
|
||||
### vs. Other Blockchains
|
||||
|
||||
- **Native Authorization**: Built-in UCAN capability system replaces external auth
|
||||
- **Gasless Onboarding**: Free vault claiming removes crypto barriers
|
||||
- **MPC Security**: Multi-party computation eliminates single points of failure
|
||||
- **WebAuthn Integration**: Hardware-backed authentication without seed phrase management
|
||||
|
||||
## Long-Term Value Thesis
|
||||
|
||||
### Sustainable Growth
|
||||
|
||||
The SNR token's value proposition centers on:
|
||||
|
||||
1. **Real Utility**: Actual usage drives demand
|
||||
2. **Network Effects**: Growth compounds value
|
||||
3. **Economic Alignment**: All participants benefit
|
||||
4. **Technical Innovation**: Continuous improvement
|
||||
|
||||
### Value Metrics
|
||||
|
||||
Key indicators of fundamental value:
|
||||
|
||||
<CardGroup>
|
||||
<Card title="Vault Claims">
|
||||
Growing number of gasless vault registrations
|
||||
</Card>
|
||||
<Card title="Service Registrations">
|
||||
TLD domain claims and capability requests
|
||||
</Card>
|
||||
<Card title="UCAN Issuance">
|
||||
Authorization activity and delegation chains
|
||||
</Card>
|
||||
<Card title="MPC Participation">
|
||||
Validator involvement in threshold signing
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
<Note>
|
||||
The SNR token represents ownership in a new paradigm of user-controlled
|
||||
internet infrastructure, with value derived from real utility, network
|
||||
effects, and sustainable economics.
|
||||
</Note>
|
||||
Reference in New Issue
Block a user