145 lines
3.9 KiB
Markdown
145 lines
3.9 KiB
Markdown
# NuQloud Pricing + Packages v1
|
|
|
|
## 1. Pricing model principles
|
|
|
|
1. No “free publishing forever” claims.
|
|
2. Publishing is metered through credits.
|
|
3. Credits are pre-funded at instance level.
|
|
4. Replication guarantees are sold as package entitlements.
|
|
5. Public UI can hide crypto internals in `powered` mode.
|
|
|
|
## 2. Core abstraction
|
|
|
|
Each instance has:
|
|
|
|
1. One publishing identity/account configured per instance through admin settings.
|
|
2. A credit balance (source of truth ledger-backed).
|
|
3. A package entitlement (replication guarantees + encrypted capacity).
|
|
|
|
Users/admins do not need to buy/manage QORT directly in standard flows.
|
|
|
|
## 3. Package catalog (v1)
|
|
|
|
### 3.1 Free Core
|
|
|
|
1. NuQloud login + identity foundation.
|
|
2. Local/off-node baseline backup features.
|
|
3. No guaranteed replication SLA.
|
|
4. No included publishing credits by default.
|
|
|
|
### 3.2 Starter
|
|
|
|
1. Included credits: `500`
|
|
2. On-instance storage: `10 GB`
|
|
3. Decentralized publish storage: `10 GB`
|
|
4. Intended audience: single-user or lighter private-cloud usage
|
|
|
|
### 3.3 Advanced
|
|
|
|
1. Included credits: `2,000`
|
|
2. On-instance storage: `25 GB`
|
|
3. Decentralized publish storage: `25 GB`
|
|
4. Intended audience: heavier single-user or hosted-account usage
|
|
|
|
### 3.4 Pro
|
|
|
|
1. Included credits: `5,000`
|
|
2. On-instance storage: `100 GB`
|
|
3. Decentralized publish storage: `100 GB`
|
|
4. Intended audience: professional-use private-cloud usage
|
|
|
|
### 3.5 Team packages
|
|
|
|
1. `nuqloud_team_starter`, `nuqloud_team_advanced`, and `nuqloud_team_pro` inherit the corresponding Starter/Advanced/Pro storage and credits.
|
|
2. Team packages are intended for up to `5` users.
|
|
|
|
### 3.6 Branded packages
|
|
|
|
1. `nuqloud_branded`: `10,000` credits, `150 GB` on-instance storage, `150 GB` decentralized publish storage.
|
|
2. `nuqloud_branded_pro`: `25,000` credits, `500 GB` on-instance storage, `500 GB` decentralized publish storage.
|
|
3. `nuqloud_branded_enterprise`: `100,000` credits, `1 TB` on-instance storage per instance, `1 TB` decentralized publish storage per instance.
|
|
|
|
### 3.7 Capacity add-on
|
|
|
|
1. `capacity-25` adds `25 GB` on-instance storage and `25 GB` decentralized publish storage.
|
|
2. `capacity-100` adds `100 GB` on-instance storage and `100 GB` decentralized publish storage.
|
|
|
|
### 3.8 Credit add-on
|
|
|
|
1. `credits-1000` is the base publishing-credit top-up.
|
|
2. `credits-5000` is the larger publishing-credit top-up.
|
|
3. Final pricing is set by finance policy and the live CHD catalog config.
|
|
|
|
## 4. Credit policy
|
|
|
|
## 4.1 Consumption
|
|
|
|
Credits are consumed when write operations are successfully committed to the NuQloud network.
|
|
|
|
## 4.2 Failure handling
|
|
|
|
If a write fails, reserved credits are refunded.
|
|
|
|
## 4.3 Balance invariants
|
|
|
|
1. No negative balances.
|
|
2. All mutations are ledger events.
|
|
3. Every event must be auditable and idempotent-safe.
|
|
|
|
## 4.4 Rollover policy
|
|
|
|
If enabled, rollover is capped (recommended max: `2x` included monthly credits).
|
|
|
|
## 5. Introductory grant policy
|
|
|
|
One-time manual bootstrap grant model:
|
|
|
|
1. One grant per instance.
|
|
2. Manual approval only.
|
|
3. Fixed Name Registration amount = `125 credits` - also given in grant.
|
|
4. Fixed default amount: `100 credits`.
|
|
5. Total amount provided `name registration 125 credits` and `100 additional publish credits`
|
|
6. Non-renewable.
|
|
7. Same ledger behavior as paid credits.
|
|
|
|
Request fields:
|
|
|
|
1. Instance domain
|
|
2. Admin email
|
|
3. Intended use category
|
|
4. Optional short note
|
|
|
|
## 6. UI language policy (customer-facing)
|
|
|
|
Use:
|
|
|
|
1. “Publishing credits”
|
|
2. “Replication guarantees”
|
|
3. “Encrypted capacity”
|
|
|
|
Avoid:
|
|
|
|
1. “Token burn”
|
|
2. “Wallet funding” (in powered mode)
|
|
3. protocol internals in normal admin UX
|
|
|
|
## 7. Customer-facing status surfaces
|
|
|
|
Admin panel must show:
|
|
|
|
1. Current package
|
|
2. Credit balance
|
|
3. Capacity usage
|
|
4. Replication health (`target vs healthy`)
|
|
5. Grant status (if applicable)
|
|
|
|
## 8. Change management
|
|
|
|
Pricing constants and package limits must be config-driven and versioned:
|
|
|
|
1. package definitions
|
|
2. included credits
|
|
3. add-on pricing
|
|
4. rollover cap
|
|
5. grant defaults
|