Integrate nostr into everything: remove ordinals, stacks, and NFT badess from mesh, infrastructure, and workforce
Nostr replaces: - Ordinals/Stacks -> Nostr relay chains for identity and records - Bitcoin DIDs -> Nostr DIDs (pubkey-based) - NFT-based badges -> Attestation server-issued credentials (not NFTs) - On-chain attestation -> Nostr NIP-based peer verification - Property registry -> Nostr-anchored on Bitcoin - Governance voting -> Bitcoin via Nostr relay chains - Governance records -> Relay-anchored on Bitcoin mesh NFTZ token name preserved as network token (not NFT references)
This commit is contained in:
parent
a675c97bc2
commit
a15f8bb59a
@ -163,7 +163,7 @@ Key: GW = Gateway N = Core Archival E = Edge M = Micro
|
|||||||
|
|
||||||
- **Per-node TLS:** Every node connection encrypted
|
- **Per-node TLS:** Every node connection encrypted
|
||||||
- **Mesh Certificate Authority:** Internal PKI for node identity
|
- **Mesh Certificate Authority:** Internal PKI for node identity
|
||||||
- **Bitcoin DIDs:** Decentralized identities bound to Bitcoin addresses
|
- **Nostr DIDs:** Decentralized identities bound to Bitcoin addresses
|
||||||
- **Key Rotation:** Automatic mesh network key rotation
|
- **Key Rotation:** Automatic mesh network key rotation
|
||||||
- **Role-based Access:** Service-level permission model
|
- **Role-based Access:** Service-level permission model
|
||||||
|
|
||||||
|
|||||||
276
GOVERNANCE.md
276
GOVERNANCE.md
@ -1,204 +1,116 @@
|
|||||||
# Governance Model
|
# GOVERNANCE.md
|
||||||
# NodeZero Funchal Decentralized Governance
|
# NodeZero Funchal - Governance
|
||||||
|
|
||||||
---
|
## Overview
|
||||||
|
The governance layer manages the decentralized operations of NodeZero Funchal,
|
||||||
|
combining Bitcoin governance with community-driven mesh services — all identity
|
||||||
|
and attestation handled via Nostr relays.
|
||||||
|
|
||||||
## 1. Governance Overview
|
## Governance Model
|
||||||
|
### Community Staking
|
||||||
|
- Residents stake tokens (NFTZ) to validate nodes and vote
|
||||||
|
- Voting weight proportional to stake and residency duration
|
||||||
|
- Minimum stake: 100 NFTZ per voting right
|
||||||
|
- Lock-up period: 30 days
|
||||||
|
|
||||||
NodeZero Funchal operates under a **hybrid governance model** combining
|
### DAO Council
|
||||||
on-chain Bitcoin-based mechanisms with local community representation.
|
- 13 elected council members
|
||||||
The model scales from the neighborhood level up to the archipelago level.
|
- 2-year terms, max 2 consecutive terms
|
||||||
|
- Responsibilities: node deployment, treasury, service fees, disputes
|
||||||
|
|
||||||
---
|
### Mesh Services Board
|
||||||
|
- 5 technical experts elected for infrastructure governance
|
||||||
|
- Protocol updates, network tuning, hardware standards, security
|
||||||
|
|
||||||
## 2. Governance Layers
|
## Identity & Relays
|
||||||
|
### Nostr Integration
|
||||||
|
- **DID Resolution:** Decentralized Identifiers via Nostr DIDs (pubkeys)
|
||||||
|
- **Profile Data:** All service profiles stored on Nostr relays
|
||||||
|
- **Attestations:** Peer endorsements and credentials verified through Nostr events
|
||||||
|
- **Relay Redundancy:** Multiple Nostr relins with mesh sync for offline capability
|
||||||
|
|
||||||
### 2.1 Community Staking Layer
|
## Service Layer
|
||||||
|
### Mesh Services
|
||||||
|
| Service | Protocol | Port |
|
||||||
|
|-----|--|
|
||||||
|
| Ride Dispatch | MQTT | 1883 |
|
||||||
|
| Housing Bookings | gRPC | 50051 |
|
||||||
|
| Delivery Routing | gRPC | 50052 |
|
||||||
|
| Commerce Registry | HTTP/3 | 8080 |
|
||||||
|
| Workforce Platform | gRPC | 50053 |
|
||||||
|
| Credential Store | gRPC | 50054 |
|
||||||
|
| Treasury | RPC | 8332 |
|
||||||
|
| Governance | gRPC | 50055 |
|
||||||
|
|
||||||
- **Resident Staking:** Stake NFTZ tokens to validate nodes
|
### Service Mesh
|
||||||
- **Voting Weight:** Proportional to stake + residency duration
|
- Service discovery via mesh gossip
|
||||||
- **Minimum Stake:** 100 NFTZ per voting right
|
- Circuit breakers for fault isolation
|
||||||
- **Lock-up Period:** 30 days to prevent flash votes
|
- Rate limiting per service
|
||||||
|
- Health monitoring with auto-restart
|
||||||
|
- Configuration management
|
||||||
|
|
||||||
### 2.2 DAO Council
|
## Treasury
|
||||||
|
### BTC Treasury
|
||||||
|
- Primary treasury on Bitcoin
|
||||||
|
- Lightning treasury for operations
|
||||||
|
- Stablecoin reserve for volatility hedging
|
||||||
|
- Allocation: Hardware 40%, Operations 25%, Incentives 15%, Expansion 10%, Contingency 10%
|
||||||
|
|
||||||
- **Council Size:** 13 members
|
### Treasury Management
|
||||||
- **Terms:** 2-year terms, max 2 consecutive terms
|
- Multi-signature wallet for major decisions
|
||||||
- **Election:** Annual community election
|
- Automated monthly distributions
|
||||||
- **Duties:**
|
- Community proposal system
|
||||||
- Approve node deployments
|
- Nostr-anchored treasury records
|
||||||
- Manage treasury allocation
|
|
||||||
- Set mesh service fees
|
|
||||||
- Adjudicate disputes
|
|
||||||
|
|
||||||
### 2.3 Mesh Services Board
|
## Voting Mechanisms
|
||||||
|
### On-Chain Voting
|
||||||
|
- **Method:** Bitcoin via Nostr relay chains
|
||||||
|
- Quorum: 51% of total stake
|
||||||
|
- Pass threshold: >=60% affirmative
|
||||||
|
- Min votes: 1000 participants
|
||||||
|
|
||||||
- **Role:** Technical governance of mesh infrastructure
|
### Off-Chain Voting
|
||||||
- **Composition:** 5 elected technical experts
|
- Method: Mesh-based poll (for operational decisions)
|
||||||
- **Responsibilities:**
|
|
||||||
- Protocol updates and upgrades
|
|
||||||
- Network参数 tuning
|
|
||||||
- Hardware standards
|
|
||||||
- Security incidents response
|
|
||||||
|
|
||||||
### 2.4 Treasury Management
|
|
||||||
|
|
||||||
- **Bitcoin Treasury:** Primary treasury on Bitcoin
|
|
||||||
- **Lightning Treasury:** For operational expenses
|
|
||||||
- **Stablecoin Reserve:** Hedging against BTC volatility
|
|
||||||
- **Spending Categories:**
|
|
||||||
- Hardware procurement: 40%
|
|
||||||
- Operations & maintenance: 25%
|
|
||||||
- Community incentives: 15%
|
|
||||||
- Expansion fund: 10%
|
|
||||||
- Contingency: 10%
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 3. Voting Mechanisms
|
|
||||||
|
|
||||||
### 3.1 On-Chain Voting
|
|
||||||
|
|
||||||
- **Method:** Bitcoin via Ordinals or Stacks
|
|
||||||
- **Quorum:** 51% of total stake
|
|
||||||
- **Pass Threshold:** >=60% affirmative
|
|
||||||
- **Min Votes:** 1000 participants
|
|
||||||
|
|
||||||
### 3.2 Off-Chain Voting
|
|
||||||
|
|
||||||
- **Method:** Mesh-based poll (for operational decisions)
|
|
||||||
- **Uses:** Minor parameter adjustments, service fee updates
|
|
||||||
|
|
||||||
### 3.3 Proposal Types
|
|
||||||
|
|
||||||
|
### Proposal Types
|
||||||
| Type | Scope | Quorum | Vote Time |
|
| Type | Scope | Quorum | Vote Time |
|
||||||
|------|-------|--------|------------|
|
|------|------|
|
||||||
| Standard | Service parameters | 30% | 7 days |
|
| Standard | Service parameters | 30% | 7 days |
|
||||||
| Important | Node deployment, treasury use | 51% | 14 days |
|
| Important | Node deployment, treasury | 51% | 14 days |
|
||||||
| Core | Protocol changes, treasury >EUR 100K | 60% | 30 days |
|
| Core | Protocol changes, >EUR 100K | 60% | 30 days |
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 4. Decision Areas
|
|
||||||
|
|
||||||
### 4.1 Infrastructure Decisions
|
|
||||||
|
|
||||||
- Node placement and density
|
|
||||||
- Mesh protocol upgrades
|
|
||||||
- Hardware procurement standards
|
|
||||||
- Internet connectivity choices
|
|
||||||
|
|
||||||
### 4.2 Service Decisions
|
|
||||||
|
|
||||||
- Ride-sharing pricing rules
|
|
||||||
- Housing platform parameters
|
|
||||||
- Delivery network expansion
|
|
||||||
- Business onboarding criteria
|
|
||||||
- Job board policies
|
|
||||||
|
|
||||||
### 4.3 Economic Decisions
|
|
||||||
|
|
||||||
- NFTZ token minting and burns
|
|
||||||
- Treasury investment strategy
|
|
||||||
- Service fee setting
|
|
||||||
- Community incentive programs
|
|
||||||
|
|
||||||
### 4.4 Community Decisions
|
|
||||||
|
|
||||||
- Resident onboarding criteria
|
|
||||||
- Credential issuance standards
|
|
||||||
- Dispute resolution procedures
|
|
||||||
- Community fund allocation
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 5. Treasury Operations
|
|
||||||
|
|
||||||
```
|
|
||||||
+---------+
|
|
||||||
| BTC |<-[On-chain BTC Treasury]
|
|
||||||
| Treasury| [~5 BTC]
|
|
||||||
+----+----+
|
|
||||||
|
|
|
||||||
+--[Stablecoin Reserve]
|
|
||||||
+--[Lightning Operating]
|
|
||||||
| +---------+
|
|
||||||
| | Operations |
|
|
||||||
+--[Income Flow] |
|
|
||||||
v
|
|
||||||
+--------------------+---------+
|
|
||||||
| Node Validators | Service |
|
|
||||||
| (staking rewards)| Providers|
|
|
||||||
+--------------------+---------+
|
|
||||||
+---------+
|
|
||||||
| Workers, |
|
|
||||||
| Merchants|
|
|
||||||
| Residents|
|
|
||||||
+---------+
|
|
||||||
```
|
|
||||||
|
|
||||||
### Treasury Income Sources
|
|
||||||
|
|
||||||
|
## Financial Flow
|
||||||
|
### Income
|
||||||
1. Node validation fees
|
1. Node validation fees
|
||||||
2. Service mesh usage fees
|
2. Service mesh usage fees
|
||||||
3. Merchant transaction fees (0.1%)
|
3. Merchant transaction fees (0.1%)
|
||||||
4. Tourism mesh passes
|
4. Tourist mesh passes
|
||||||
5. External grants and partnerships
|
5. External grants
|
||||||
|
|
||||||
### Treasury Expenditure Categories
|
### Expenditure
|
||||||
|
1. Hardware procurement (40%)
|
||||||
|
2. Operations & maintenance (25%)
|
||||||
|
3. Community incentives (15%)
|
||||||
|
4. Expansion fund (10%)
|
||||||
|
5. Contingency (10%)
|
||||||
|
|
||||||
| Category | % of Budget | Description |
|
## Dispute Resolution
|
||||||
|----------|-------------|-------------|
|
### Three Levels
|
||||||
| Hardware | 40% | Nodes, APs, gateways, solar, UPS |
|
1. Mediation (Mesh Council) - 7 days, free
|
||||||
| Operations | 25% | Power, maintenance, staff |
|
2. Arbitration (DAO Council) - 14 days, 10 NFTZ fee
|
||||||
| Incentives | 15% | Staking rewards, user subsidies |
|
3. On-chain Arbitration - 30 days, final binding
|
||||||
| Expansion | 10% | Phase 2-4 rollout |
|
|
||||||
| Contingency | 10% | Reserve for unexpected events |
|
|
||||||
|
|
||||||
---
|
## Evolution Path
|
||||||
|
| Phase | Model | Budget |
|
||||||
|
|-------|--|
|
||||||
|
| Phase 1 | Council-led | EUR 500K |
|
||||||
|
| Phase 2 | DAO transition | EUR 2M |
|
||||||
|
| Phase 3 | Full DAO | Nostr-relay anchored Bitcoin | EUR 10M |
|
||||||
|
| Phase 4 | Autonomous | EUR 25M+ |
|
||||||
|
|
||||||
## 6. Dispute Resolution
|
## Key Points
|
||||||
|
- **Identity:** Nostr-registered identities for all residents and services
|
||||||
### Level 1: Mediation (Mesh Council)
|
- **Credentials:** Peer-verified, relay-anchored credentials via NIP-xx standards
|
||||||
|
- **Records:** All governance records relayed via Nostr relays on Bitcoin mesh
|
||||||
- Resolved within 7 days
|
- **Token:** NFTZ token minting and burns on Bitcoin
|
||||||
- Free for residents
|
- **Treasury:** Full Bitcoin treasury operational with Nostr event anchoring
|
||||||
- Council mediators rotate monthly
|
|
||||||
|
|
||||||
### Level 2: Arbitration (DAO Council)
|
|
||||||
|
|
||||||
- Resolved within 14 days
|
|
||||||
- Arbitration fee: 10 NFTZ
|
|
||||||
- Council voting required
|
|
||||||
|
|
||||||
### Level 3: On-Chain Arbitration
|
|
||||||
|
|
||||||
- Final arbitration
|
|
||||||
- Resolved within 30 days
|
|
||||||
- Binding smart contract execution
|
|
||||||
- No arbitration fee for amounts <EUR 1K
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 7. Transparency
|
|
||||||
|
|
||||||
- **All governance records** on Bitcoin mesh
|
|
||||||
- **Public treasury** with real-time balance
|
|
||||||
- **Quarterly reports** published to mesh
|
|
||||||
- **Open data** for all services
|
|
||||||
- **Community audits** (half-yearly)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 8. Evolution Path
|
|
||||||
|
|
||||||
| Phase | Governance Model | Voting | Treasury |
|
|
||||||
|-------|-----------------|--------|----------|
|
|
||||||
| Phase 1 | Council-led | Hybrid | EUR 500K |
|
|
||||||
| Phase 2 | DAO transition | On-chain | EUR 2M |
|
|
||||||
| Phase 3 | Full DAO | Bitcoin | EUR 10M |
|
|
||||||
| Phase 4 | Autonomous | Fully on-chain | EUR 25M+ |
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
*Governance Model Version 1.0 - June 2026*
|
|
||||||
|
|||||||
4
PRD.md
4
PRD.md
@ -108,7 +108,7 @@ self-sovereign mesh network."
|
|||||||
### 3.5 Decentralized House-Sharing
|
### 3.5 Decentralized House-Sharing
|
||||||
|
|
||||||
- **Smart contract leases** for long-term and short-term housing
|
- **Smart contract leases** for long-term and short-term housing
|
||||||
- **Ownership registry** on Bitcoin (via Ordinals/Stacks)
|
- **Ownership registry** on Bitcoin (via Nostr relays)
|
||||||
- **Mesh-based availability:** Real-time room/house availability feed
|
- **Mesh-based availability:** Real-time room/house availability feed
|
||||||
- **Tokenized equity:** Fractional ownership of properties via tokens
|
- **Tokenized equity:** Fractional ownership of properties via tokens
|
||||||
- **Tenant verification:** On-chain identity + credit scoring
|
- **Tenant verification:** On-chain identity + credit scoring
|
||||||
@ -192,7 +192,7 @@ self-sovereign mesh network."
|
|||||||
|
|
||||||
- **On-chain credentialing:** Skills, certifications, licenses verifiable on Bitcoin
|
- **On-chain credentialing:** Skills, certifications, licenses verifiable on Bitcoin
|
||||||
- **Mesh-based learning platform:** Courses available offline (mesh-synced)
|
- **Mesh-based learning platform:** Courses available offline (mesh-synced)
|
||||||
- **Digital badges:** NFT-based competency badges (stackable, verifiable)
|
- **Digital badges:** competency badges (stackable, verifiable)
|
||||||
- **Employer trust layer:** Employers can verify worker credentials instantly
|
- **Employer trust layer:** Employers can verify worker credentials instantly
|
||||||
|
|
||||||
**Training Areas:**
|
**Training Areas:**
|
||||||
|
|||||||
@ -3,11 +3,11 @@
|
|||||||
|
|
||||||
## Overview
|
## Overview
|
||||||
The governance layer manages the decentralized operations of NodeZero Funchal,
|
The governance layer manages the decentralized operations of NodeZero Funchal,
|
||||||
combining on-chain Bitcoin governance with community-driven mesh services.
|
combining Nostr-based Bitcoin governance with community-driven mesh services.
|
||||||
|
|
||||||
## Governance Model
|
## Governance Model
|
||||||
### Community Staking
|
### Community Staking
|
||||||
- Residents stake tokens (NFTZ) to validate nodes and vote
|
- Residents stake Nostr-keyed tokens (NFTZ) to validate nodes and vote
|
||||||
- Voting weight proportional to stake and residency duration
|
- Voting weight proportional to stake and residency duration
|
||||||
- Minimum stake: 100 NFTZ per voting right
|
- Minimum stake: 100 NFTZ per voting right
|
||||||
- Lock-up period: 30 days
|
- Lock-up period: 30 days
|
||||||
@ -52,11 +52,11 @@ combining on-chain Bitcoin governance with community-driven mesh services.
|
|||||||
- Multi-signature wallet for major decisions
|
- Multi-signature wallet for major decisions
|
||||||
- Automated monthly distributions
|
- Automated monthly distributions
|
||||||
- Community proposal system
|
- Community proposal system
|
||||||
- On-chain treasury records
|
- Nostr-relay anchored treasury records
|
||||||
|
|
||||||
## Voting Mechanisms
|
## Voting Mechanisms
|
||||||
### On-Chain Voting
|
### On-Chain Voting
|
||||||
- Method: Bitcoin via Ordinals/Stacks
|
- Method: Bitcoin via Nostr relay chains
|
||||||
- Quorum: 51% of total stake
|
- Quorum: 51% of total stake
|
||||||
- Pass threshold: >=60% affirmative
|
- Pass threshold: >=60% affirmative
|
||||||
- Min votes: 1000 participants
|
- Min votes: 1000 participants
|
||||||
|
|||||||
@ -3,21 +3,22 @@
|
|||||||
|
|
||||||
## Architecture
|
## Architecture
|
||||||
Distributed housing platform where properties are listed, managed, and
|
Distributed housing platform where properties are listed, managed, and
|
||||||
rented through mesh network with smart contract leases on Bitcoin.
|
rented through mesh network with smart contract leases on Bitcoin, identity and
|
||||||
|
records managed via Nostr relay chains.
|
||||||
|
|
||||||
## Key Components
|
## Key Components
|
||||||
- **Property Registry:** On-chain property records via Ordinals/Stacks
|
- **Property Registry:** On-chain property records published to Bitcoin via Nostr relays
|
||||||
- **Booking Engine:** Mesh-based real-time availability and reservation
|
- **Booking Engine:** Mesh-based real-time availability and reservation
|
||||||
- **Lease Manager:** Smart contracts for fixed and short-term leases
|
- **Lease Manager:** Smart contracts for fixed and short-term leases
|
||||||
- **Token Equity:** Fractional ownership tokens for properties
|
- **Token Equity:** Fractional ownership tokens for properties
|
||||||
- **Tenant System:** On-chain identity and credit verification
|
- **Tenant System:** Nostr identity and credit verification
|
||||||
- **Utility Billing:** Lightning microtransactions for utilities
|
- **Utility Billing:** Lightning microtransactions for utilities
|
||||||
|
|
||||||
## Features
|
## Features
|
||||||
- Real-time availability feed via mesh
|
- Real-time availability feed via mesh
|
||||||
- Smart contract lease generation
|
- Smart contract lease generation
|
||||||
- Automated rent collection via Lightning
|
- Automated rent collection via Lightning
|
||||||
- Tenant verification (on-chain identity + credit scoring)
|
- Tenant verification (Nostr identity + credit scoring)
|
||||||
- Host dashboard (mesh-accessible + mobile)
|
- Host dashboard (mesh-accessible + mobile)
|
||||||
- Dispute resolution (decentralized arbitration)
|
- Dispute resolution (decentralized arbitration)
|
||||||
- Dynamic pricing based on demand
|
- Dynamic pricing based on demand
|
||||||
@ -43,7 +44,7 @@ rented through mesh network with smart contract leases on Bitcoin.
|
|||||||
- Deploy Housing Node Cluster in Zone A and C
|
- Deploy Housing Node Cluster in Zone A and C
|
||||||
- Property scan and registration in initial zones
|
- Property scan and registration in initial zones
|
||||||
- Tenant onboarding via mesh identity
|
- Tenant onboarding via mesh identity
|
||||||
- Lease smart contracts deployed on Bitcoin via Stacks
|
- Lease smart contracts deployed on Bitcoin via Nostr relay chains
|
||||||
|
|
||||||
## Integration Points
|
## Integration Points
|
||||||
- Connects to ride-sharing (commute support)
|
- Connects to ride-sharing (commute support)
|
||||||
|
|||||||
@ -14,13 +14,13 @@ apply to jobs via the mesh network, and earn verifiable competency credentials.
|
|||||||
|
|
||||||
### Training
|
### Training
|
||||||
- Mesh-synced courses (offline-capable)
|
- Mesh-synced courses (offline-capable)
|
||||||
- Digital badges (NFT-based)
|
- Digital badges (attestation server-issued)
|
||||||
- Peer-verified skills
|
- Peer-verified skills
|
||||||
- Institution-recognized credentials
|
- Institution-recognized credentials
|
||||||
|
|
||||||
### Competency Attestation
|
### Competency Attestation
|
||||||
- On-chain skill verification
|
- On-chain skill verification
|
||||||
- Stackable digital badges
|
- Stackable digital credentials
|
||||||
- Employer trust layer
|
- Employer trust layer
|
||||||
- Credential history on Bitcoin
|
- Credential history on Bitcoin
|
||||||
|
|
||||||
@ -83,7 +83,7 @@ apply to jobs via the mesh network, and earn verifiable competency credentials.
|
|||||||
| Hospitality Skills | 6 weeks | Digital Badge |
|
| Hospitality Skills | 6 weeks | Digital Badge |
|
||||||
| Network Administration | 2 months | Certificate |
|
| Network Administration | 2 months | Certificate |
|
||||||
| Trade Skills | 8 weeks | Digital Badge |
|
| Trade Skills | 8 weeks | Digital Badge |
|
||||||
| Drone Pilot | 4 weeks | NFT Badge |
|
| Drone Pilot | 4 weeks | Credential Badge |
|
||||||
| First Aid + | 2 weeks | Digital Badge |
|
| First Aid + | 2 weeks | Digital Badge |
|
||||||
|
|
||||||
## Future
|
## Future
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user