Core System Architecture Part 54 — Anonymous Network Economics, Incentives, Operator Sustainability, Subsidies & Privacy-Preserving Compensation Architecture
SIAR — Secure, Local-First, Multi-Transport Communication Platform
Series: Core System Architecture
Part: 54
Status: Architecture specification
Primary language: Rust
Builds on: Core System Architecture Parts 34–53
Primary purpose: define the complete economic and sustainability architecture for SIAR's anonymous infrastructure, including operator compensation, sustainable pricing, subsidies, reserve pools, public-good funding, anti-gaming controls, privacy-preserving settlement, emergency support, and strict separation between economics, routing, identity, and governance.
1. Purpose
Anonymous infrastructure costs money.
Operators pay for:
servers
bandwidth
storage
power
cloud egress
hardware
security
monitoring
staff
compliance
If incentives are poorly designed, the network may suffer from:
centralization
pay-to-win routing
fake capacity
Sybil operators
traffic manipulation
speculative token economics
unfair subsidies
operator churn
The governing principle is:
SIAR economics should make privacy-preserving infrastructure sustainable without turning operator compensation into a mechanism for user tracking, routing manipulation, speculation, or governance capture.
2. Architectural Position
User / Organization Funding
│
▼
Credit Issuance
│
▼
Service-Specific Usage
│
▼
Signed Service Receipts
│
▼
Aggregate Settlement
│
▼
Operator Compensation
│
├── direct usage revenue
├── subsidies
├── grants
└── reserve support
3. Core Separation
Keep distinct:
user payment
service usage
operator compensation
governance influence
routing weight
reputation
subsidy eligibility
4. Non-Goals
Part 54 does not require:
cryptocurrency
tradeable network token
proof-of-stake governance
speculative mining
user identity-linked billing
operator voting power based on wealth
5. Economic Actors
#![allow(unused)] fn main() { pub enum EconomicActor { User, Organization, ServiceProvider, Operator, SubsidyFund, GovernanceBody, SettlementService, } }
6. Service Provider
Offers:
mailbox
relay
bulk storage
mix gateway
bridge
7. Operator
Controls one or more providers.
8. Subsidy Fund
Supports services that cannot rely solely on direct user fees.
9. Settlement Service
Aggregates receipts and pays operators.
10. Economic Principles
Mandatory:
privacy before profit
no pay-to-route preference
no wealth-based governance
no user-level payout tracing
no packet-level payment linkage
11. Operator Cost Model
Operators have real costs.
12. Cost Classes
#![allow(unused)] fn main() { pub enum OperatorCostClass { Compute, Bandwidth, Storage, Egress, Power, Hardware, Operations, Security, } }
13. Cost Model
#![allow(unused)] fn main() { pub struct OperatorCostModel { pub fixed_monthly: u64, pub variable: Vec<VariableCost>, } }
14. Variable Cost
#![allow(unused)] fn main() { pub struct VariableCost { pub class: OperatorCostClass, pub unit: ResourceUnit, pub cost_per_unit: u64, } }
15. Why Cost Model Matters
Sustainable prices should be grounded in:
real operational cost
+
reasonable reserve
+
operator margin
not arbitrary speculation.
16. Revenue Sources
Potential:
usage fees
subscriptions
organization grants
public-good subsidies
donations
operator sponsorship
17. Revenue Mix
A resilient network should not depend on one source.
18. Direct Usage Revenue
Part 47 service credits.
19. Subscription Revenue
Subscription can periodically issue:
resource credits
without provider learning user account identity.
20. Organization Grants
Useful for:
schools
NGOs
enterprises
communities
21. Public-Good Subsidy
Supports services such as:
bridges
entry gateways
emergency capacity
where direct metering is harmful or impractical.
22. Donation Funding
Can feed subsidy pool.
23. No Routing Influence From Donation
Hard rule.
24. Operator Revenue Classes
#![allow(unused)] fn main() { pub enum OperatorRevenueClass { Usage, Reservation, SubscriptionAllocation, Subsidy, Grant, } }
25. Settlement Flow
service usage
→ signed receipt
→ aggregation
→ operator settlement
26. Aggregate Settlement
Operator receives:
total valid units
total compensation
period
service class
27. No User Mapping
Hard rule.
28. Operator Settlement
#![allow(unused)] fn main() { pub struct OperatorEconomicSettlement { pub operator: ProviderOperatorId, pub period: AccountingPeriod, pub service: AnonymousServiceType, pub billable_units: u64, pub gross_amount: u64, pub subsidy_amount: u64, pub fees: u64, pub net_amount: u64, } }
29. Settlement Inputs
Only:
valid receipts
pricing
subsidy policy
operator eligibility
30. Routing Must Not Depend On Operator Revenue
Hard rule.
31. Pay-To-Win Risk
If high-paying operator gets more traffic, centralization follows.
32. Therefore
Provider selection from Part 48 remains based on:
privacy
eligibility
diversity
health
capacity
cost
not operator sponsorship.
33. Incentive Goals
Incentives should encourage:
availability
capacity
diversity
security
long-term participation
34. Incentive Signals
Potential:
uptime class
capacity delivered
successful reservations
audit status
region diversity
35. No Per-User Performance Reward
Hard rule.
36. Operator Quality Multiplier
Possible.
37. Quality Multiplier
#![allow(unused)] fn main() { pub struct OperatorQualityMultiplier(pub f32); }
38. Inputs
Only aggregate:
uptime
service correctness
policy compliance
capacity reliability
39. Cap Multiplier
Prevent runaway advantage.
40. New Operator Support
New operators may need bootstrap support.
41. Probation Subsidy
#![allow(unused)] fn main() { pub struct NewOperatorSubsidy { pub duration: Duration, pub max_amount: u64, } }
42. Goal
Reduce entry barrier without granting full traffic dominance.
43. Operator Diversity Subsidy
Potentially reward:
underrepresented region
underrepresented ASN
independent operator
44. Privacy Benefit
More diversity improves anonymity resilience.
45. Subsidy Rule
Must not rely on user identity.
46. Subsidy Categories
#![allow(unused)] fn main() { pub enum SubsidyCategory { Diversity, Emergency, PublicGood, Bootstrap, CapacityReserve, CensorshipResistance, } }
47. Diversity Subsidy
Supports regions/operators lacking capacity.
48. Emergency Subsidy
Funds spare capacity during disaster.
49. Public-Good Subsidy
For infrastructure with weak direct monetization.
50. Bootstrap Subsidy
For early network growth.
51. Capacity Reserve Subsidy
Pays operators to maintain unused headroom.
52. Censorship-Resistance Subsidy
Supports:
bridges
alternate transports
53. Subsidy Fund
#![allow(unused)] fn main() { pub struct SubsidyFund { pub fund_id: SubsidyFundId, pub category: SubsidyCategory, pub budget: u64, pub policy_version: GovernancePolicyVersion, } }
54. Subsidy Governance
Part 53 governance controls:
eligibility
budget
duration
review
55. No Automatic Unlimited Subsidy
Hard rule.
56. Budget Caps
Required.
57. Time-Limited Programs
Preferred.
58. Subsidy Eligibility
Could require:
active operator
healthy provider
minimum audit class
capacity commitment
59. Subsidy Claim
#![allow(unused)] fn main() { pub struct SubsidyClaim { pub operator: ProviderOperatorId, pub category: SubsidyCategory, pub period: AccountingPeriod, pub evidence: SubsidyEvidence, } }
60. Subsidy Evidence
Aggregate only.
61. Examples
capacity maintained
uptime bucket
independent region
bridge availability
62. No User-Level Subsidy Evidence
Hard rule.
63. Public-Good Funding Model
Some services should be funded from pool.
64. Good Candidates
directory mirrors
bridge infrastructure
emergency relays
public bootstrap gateways
65. Why
Charging every use may:
harm access
increase linkage
reduce resilience
66. Cross-Subsidy
Profitable services can fund public goods.
67. Cross-Subsidy Pool
#![allow(unused)] fn main() { pub struct CrossSubsidyPolicy { pub source_services: Vec<AnonymousServiceType>, pub target_categories: Vec<SubsidyCategory>, pub contribution_rate: f32, } }
68. Contribution Rate
Governed.
69. No Hidden Tax
User-facing pricing should explain service fee structure at product level.
70. Reserve Fund
Network should maintain financial reserve.
71. Reserve Purposes
region outage
capacity spike
operator exit
emergency deployment
72. Reserve Policy
#![allow(unused)] fn main() { pub struct NetworkReservePolicy { pub minimum_months: u8, pub maximum_draw_per_period: u64, } }
73. Reserve Isolation
Reserve cannot be casually used for unrelated spending.
74. Operator Exit Risk
Provider may shut down.
75. Exit Support
Could fund:
migration
grace period
temporary replacement capacity
76. Exit Bond
Potential future.
77. Bond Tradeoff
Can discourage small operators.
78. Initial Recommendation
Do not require large financial bond initially.
79. Alternative
Use:
probation
capacity caps
reputation
reserve fund
80. Sybil Operator Economics
Attacker may create many operators to capture subsidies.
81. Defense
Use Part 39:
operator identity
admission
probation
diversity validation
82. Subsidy Sybil Defense
Do not pay per operator count.
83. Better
Pay for:
verified useful capacity
independent failure domain
audited operation
84. Fake Capacity
Operator advertises capacity to earn subsidy.
85. Defense
Independent probes.
86. Paid Capacity Verification
#![allow(unused)] fn main() { pub struct VerifiedCapacityRecord { pub operator: ProviderOperatorId, pub service: AnonymousServiceType, pub capacity_class: CapacityClass, pub verification: CapacityVerificationClass, } }
87. Capacity Verification Class
#![allow(unused)] fn main() { pub enum CapacityVerificationClass { SelfReported, Observed, IndependentlyVerified, } }
88. Subsidy Weight
Higher assurance gets higher confidence.
89. Uptime Incentive
Potential compensation bonus.
90. Avoid Perfection Trap
Do not make small outage economically catastrophic.
91. Use Buckets
Healthy
Good
Degraded
Poor
92. Uptime Class
#![allow(unused)] fn main() { pub enum EconomicUptimeClass { Excellent, Good, Acceptable, Poor, } }
93. Compensation Curve
Should be smooth.
94. No Cliff Incentive
Avoid:
99.9% gets paid
99.89% gets nothing
95. Capacity Commitment
Provider may commit reserve capacity.
96. Commitment Contract
#![allow(unused)] fn main() { pub struct CapacityCommitment { pub operator: ProviderOperatorId, pub resource: InfrastructureResource, pub class: CapacityClass, pub period: AccountingPeriod, } }
97. Reserve Compensation
Pay for maintaining headroom even if unused.
98. Why
Needed for disaster resilience.
99. Emergency Draw
During Part 50 disaster mode, reserve capacity activates.
100. Emergency Premium
Could compensate higher costs.
101. Privacy
Still aggregate.
102. Bridge Economics
Bridges are often censorship-sensitive.
103. Direct Billing Risk
Bridge payments may reveal:
who needs censorship bypass
104. Recommendation
Subsidize bridges from public-good pool.
105. Realtime Relay Economics
Can be usage-based.
106. Mailbox Economics
Can use storage/retention credits.
107. Bulk Economics
Can use storage + egress.
108. Mixnet Economics
Per-packet payment is dangerous.
109. Better
Use:
gateway quota
provider settlement aggregate
subsidy/revenue pool
110. Mix Node Compensation
Potentially based on:
capacity
uptime
validated forwarding availability
not individual packet receipts.
111. Why
Avoid packet-level economic fingerprint.
112. Node Compensation Pool
#![allow(unused)] fn main() { pub struct MixnetCompensationPool { pub period: AccountingPeriod, pub budget: u64, } }
113. Distribution Factors
eligible capacity
availability
operator diversity
layer participation
114. Cap Dominance
One operator cannot capture unlimited share.
115. Maximum Operator Share
Governance policy.
116. Economic Concentration Metric
#![allow(unused)] fn main() { pub struct EconomicConcentration { pub operator_share: f32, pub top_n_share: f32, } }
117. High Concentration
Triggers:
review
subsidy adjustment
new-operator incentives
118. No Forced Routing Redistribution
Economic concern should not override privacy.
119. Anti-Centralization Subsidy
Can support underrepresented providers.
120. Price Competition
Providers may set prices.
121. Price Floor
Potential to prevent predatory underpricing.
122. Price Ceiling
Potential for essential public services.
123. Governance Caution
Avoid over-central planning.
124. Initial Recommendation
Use:
transparent signed prices
local selection
subsidy for public goods
rather than hard price controls.
125. Free Tier
Important for accessibility.
126. Free Tier Funding
Can come from:
cross-subsidy
donations
reserve
organization grants
127. Free Tier Abuse
Use Part 47 quota controls.
128. No Identity Requirement Just For Free Tier
Hard rule where avoidable.
129. Community-Sponsored Access
Organization can issue credits.
130. Sponsorship Privacy
Organization may know recipient.
Provider should not learn communication details.
131. Gift Credits
Issuer-mediated.
132. User-to-User Transfer
Still discouraged in initial design.
133. Operator Payout Privacy
Operator payout account is not user privacy issue.
134. Operator Financial Identity
May be known to settlement system.
135. Separate From Provider Runtime Identity
Hard rule.
136. Payout Adapter
#![allow(unused)] fn main() { pub trait OperatorPayoutAdapter { fn payout( &self, settlement: &OperatorEconomicSettlement, ) -> Result<PayoutReceipt, EconomicError>; } }
137. Payout Methods
Architecture can support:
bank
payment processor
organization invoice
138. No Requirement For Crypto Payment
Hard rule.
139. Settlement Currency
Can be fiat.
140. Internal Resource Unit
Separate from currency.
141. Why
Avoid coupling protocol to one monetary system.
142. Economic Unit
#![allow(unused)] fn main() { pub struct EconomicUnit(pub u64); }
143. Conversion
Price catalog maps resource unit to currency/credit.
144. Multi-Currency
Funding layer can support.
145. Provider Price Publication
Signed.
146. Price Change Frequency
Coarse.
147. No Millisecond Dynamic Pricing
Hard rule.
148. Market Stability
Avoid extreme oscillation.
149. Price Smoothing
Potential:
epoch average
bounded delta
150. Maximum Price Delta
Governance/business policy.
151. Subsidy Smoothing
Likewise.
152. Economic Attack
Provider artificially congests service to trigger higher subsidy/price.
153. Defense
Independent health/capacity evidence.
154. Demand Manipulation
Attacker generates fake load to affect market.
155. Defense
Use:
validated reservations
paid quota
aggregate demand
156. Wash Usage
Operator generates fake usage to pay itself.
157. Defense
Credits/receipts must represent genuine external spend where applicable.
158. Public-Good Service
For subsidy-funded service, rely on:
independent availability proof
capacity evidence
159. No Self-Reported Payout Only
Hard rule.
160. Settlement Fraud
Potential:
forged receipt
duplicate receipt
inflated unit count
161. Defense
Part 47 signed receipt/idempotent settlement.
162. Subsidy Fraud
Potential:
fake operator
fake region
fake capacity
163. Defense
Part 39/48 governance + independent verification.
164. Economic Reputation
Keep separate from privacy trust.
165. Operator Economic Record
Can track:
settlement correctness
capacity commitment
subsidy compliance
166. No User Reputation Mixing
Hard rule.
167. Operator Economic State
#![allow(unused)] fn main() { pub enum OperatorEconomicState { Normal, UnderReview, SubsidySuspended, SettlementSuspended, } }
168. Suspension
Does not automatically revoke network operation unless governance separately decides.
169. Why
Economic dispute ≠ security compromise.
170. Governance Separation
Part 53 controls operator revocation.
171. Economic System Cannot Revoke Anonymity Provider Alone
Hard rule.
172. Subsidy Governance Workflow
proposal
→ budget approval
→ eligibility rules
→ signed program
→ claims
→ audit
→ renewal/expiry
173. Subsidy Program
#![allow(unused)] fn main() { pub struct SubsidyProgram { pub program_id: SubsidyProgramId, pub category: SubsidyCategory, pub budget: u64, pub start: Timestamp, pub end: Timestamp, pub rules: SubsidyEligibilityRules, pub policy_version: GovernancePolicyVersion, } }
174. Mandatory End Date
Preferred.
175. Renewal
Explicit governance action.
176. Emergency Subsidy
Short expiry.
177. Subsidy Claim Review
Automated where evidence clear.
Manual for anomaly.
178. Claim Privacy
No user data.
179. Public Transparency
Can publish:
subsidy budgets
operator grants
program totals
180. Privacy
Operator-level financial data may be public if policy says so.
181. User Usage Not Public
Hard rule.
182. Economic Transparency Report
Possible:
total operator payouts
public-good spending
reserve level
concentration
183. Differential Privacy
Likely unnecessary for large aggregate financial totals.
184. Small Operator Consideration
Avoid publishing highly granular traffic-derived payout if it reveals sensitive load.
185. Coarse Disclosure
Can publish ranges.
186. Sustainability SLOs
Examples:
operator churn
capacity reserve
public-good coverage
settlement delay
187. Economic Health Classes
#![allow(unused)] fn main() { pub enum NetworkEconomicHealth { Healthy, Tight, Underfunded, Critical, } }
188. Underfunded
Means:
reserve or subsidy insufficient
189. User Impact
May cause:
higher price
lower free tier
reduced public-good capacity
but not privacy downgrade.
190. Hard Rule
Financial shortage never enables weaker anonymity path automatically.
191. Economic Forecasting
Useful.
192. Inputs
Aggregate:
capacity
cost trends
settlement
reserve
growth
193. No Per-User Forecasting Needed
Hard rule.
194. Forecast Model
Local control-plane service.
195. Cost Shock
Example:
cloud egress rises
196. Response
price update
subsidy adjustment
operator migration
197. Multi-Operator Sustainability
Avoid dependency on one subsidized operator.
198. Minimum Operator Count
Can be governance target.
199. Economic Diversity Target
#![allow(unused)] fn main() { pub struct EconomicDiversityTarget { pub minimum_operators: usize, pub maximum_top_operator_share: f32, } }
200. Incentive for Underrepresented Region
Can help resilience.
201. Carbon/Energy Consideration
Optional.
202. Energy Efficiency Incentive
Could reward:
lower energy per resource unit
203. Privacy
No user linkage.
204. Caution
Do not make opaque environmental scoring core to anonymity.
205. Operator Reporting
Provider can submit:
cost class
capacity
resource usage
206. Self-Reported Cost
Not fully trusted.
207. Reimbursement Programs
Need evidence.
208. General Subsidy
Better than exact cost reimbursement in many cases.
209. Why
Reduces accounting complexity and incentive to inflate costs.
210. Operator Marketplace Exit
If revenue falls:
retire provider gracefully
211. Exit Notice
Signed.
212. Continuity
Part 50 migrates affected services.
213. New Operator Entry
Part 39/48 admission.
214. Economic Bootstrap
Part 54 can support initial subsidy.
215. Infrastructure Grant
#![allow(unused)] fn main() { pub struct InfrastructureGrant { pub operator: ProviderOperatorId, pub purpose: SubsidyCategory, pub amount: u64, pub period: AccountingPeriod, } }
216. Grant Milestones
Potential:
deploy
pass audit
maintain capacity
217. Clawback
Possible for fraud.
218. Clawback Governance
Requires evidence and due process.
219. No Automatic Clawback For Outage
Hard rule.
220. Reserve Draw
Governed event.
221. Reserve Draw Record
#![allow(unused)] fn main() { pub struct ReserveDraw { pub amount: u64, pub reason: ReserveDrawReason, pub policy_version: GovernancePolicyVersion, } }
222. Reserve Draw Reason
#![allow(unused)] fn main() { pub enum ReserveDrawReason { Disaster, CapacityShortage, OperatorExit, EmergencyBridgeDeployment, } }
223. Reserve Replenishment
From:
service fees
donations
budget allocation
224. Network Foundation Model
Possible organizational model.
225. Architecture Neutrality
SIAR protocol should not require one legal entity.
226. Multiple Funding Entities
Future.
227. Federation
Different governance domains may fund own operators.
228. Economic Interoperability
Resource credits could remain domain-specific.
229. Cross-Domain Settlement
Future complexity.
230. Initial Recommendation
Single settlement/governance domain.
231. Compensation Policy
#![allow(unused)] fn main() { pub struct CompensationPolicy { pub version: GovernancePolicyVersion, pub service_rates: Vec<ServiceCompensationRate>, pub quality_multipliers: Vec<QualityRule>, pub concentration_caps: EconomicDiversityTarget, } }
232. Compensation Rate
#![allow(unused)] fn main() { pub struct ServiceCompensationRate { pub service: AnonymousServiceType, pub resource: ResourceUnit, pub rate: u64, } }
233. Policy Signed
Part 53 governance.
234. No Hidden Compensation Algorithm
Hard rule.
235. Operator Can Reproduce Settlement
Recommended.
236. Settlement Determinism
Same inputs -> same result.
237. Settlement Engine
#![allow(unused)] fn main() { pub trait OperatorSettlementEngine { fn settle( &self, period: AccountingPeriod, receipts: &[ValidatedServiceReceipt], policy: &CompensationPolicy, ) -> Result<Vec<OperatorEconomicSettlement>, EconomicError>; } }
238. Subsidy Engine
#![allow(unused)] fn main() { pub trait SubsidyEngine { fn evaluate( &self, claim: &SubsidyClaim, program: &SubsidyProgram, ) -> Result<SubsidyDecision, EconomicError>; } }
239. Subsidy Decision
#![allow(unused)] fn main() { pub enum SubsidyDecision { Approved(u64), Rejected(SubsidyRejectionReason), ManualReview, } }
240. Economic Health Monitor
#![allow(unused)] fn main() { pub trait EconomicHealthMonitor { fn evaluate( &self, state: &AggregateEconomicState, ) -> NetworkEconomicHealth; } }
241. Aggregate Economic State
Contains:
reserve
operator churn
settlement delay
capacity coverage
242. No User Billing Details
Hard rule.
243. Operator Cost Privacy
Operators may consider exact costs commercially sensitive.
244. Governance View
Can use coarse ranges.
245. Public View
Even coarser.
246. Financial Audit
May require detailed operator financial records.
247. Separate From Network Telemetry
Hard rule.
248. Financial Auditor
Does not gain user traffic data.
249. Tax/Compliance
Operator payouts may need tax documentation.
250. Keep At Settlement Boundary
Hard rule.
251. No Tax Identity In Provider Protocol
Hard rule.
252. Economic Observability
Safe metrics:
settlement latency
reserve level
operator count
capacity funded
subsidy burn
253. Forbidden Metrics
No:
user payment + provider usage linkage
contact-level spend
route-level revenue
254. Economic Incident Types
#![allow(unused)] fn main() { pub enum EconomicIncident { SettlementBacklog, SubsidyFraud, ReserveShortfall, OperatorExit, CapacityUnderfunding, PricingError, } }
255. Pricing Error
Could harm availability.
256. Response
Correct price policy.
No security bypass.
257. Settlement Outage
Providers may continue using accrued signed receipts.
258. Deferred Settlement
Supported.
259. Long Outage
Reserve liquidity may matter.
260. Operator Credit Line
Future business mechanism.
261. Not Protocol Requirement
Hard rule.
262. Economic Abuse Tests
Need simulator.
263. Scenarios
one operator underprices
fake capacity
wash usage
subsidy Sybil
mass operator exit
cost shock
reserve depletion
264. Market Concentration Simulation
Track:
operator share
regional diversity
service diversity
265. Sustainability Simulation
Project:
revenue
cost
subsidy
reserve
266. Privacy Simulation
Check compensation data cannot reconstruct user behavior.
267. Wash Usage Test
Operator cannot trivially pay itself with forged usage.
268. Fake Capacity Test
Subsidy requires independent evidence.
269. Sybil Subsidy Test
Many related operators cannot multiply subsidy unfairly.
270. Concentration Test
Subsidy does not create dominant operator.
271. Price Shock Test
Client/provider market stabilizes.
272. Reserve Shock Test
Network continues under disaster.
273. Settlement Replay Test
Duplicate settlement rejected.
274. Claim Replay Test
Duplicate subsidy claim rejected.
275. Fuzzing
Fuzz:
compensation policy
subsidy claim
settlement batch
reserve draw
276. Property Tests
Properties:
same receipt cannot pay twice
operator compensation does not alter routing eligibility
subsidy claim cannot exceed program budget
reserve draw cannot exceed configured policy
277. Formal Verification Targets
Strong candidates:
settlement idempotency
subsidy budget accounting
reserve policy
concentration cap enforcement
278. TLA+ Candidate
Subsidy allocation under concurrent claims.
279. Kani Candidate
Settlement arithmetic/overflow/budget bounds.
280. Loom Candidate
Concurrent settlement batch processing.
281. Performance Tests
Measure:
receipt aggregation
settlement computation
subsidy evaluation
market simulation
282. Scale Tests
Millions of receipts.
Thousands of providers.
283. Precision
Use integer/fixed-point arithmetic.
284. No Floating Money Arithmetic
Hard rule.
285. Decimal Representation
Use exact integer smallest unit or reviewed fixed-decimal type.
286. Overflow Safety
Checked arithmetic.
287. Rounding
Explicit policy.
288. Crate Layout
Recommended:
crates/
├── siar-economics-core/
├── siar-operator-cost/
├── siar-compensation/
├── siar-subsidy/
├── siar-reserve/
├── siar-economic-policy/
├── siar-economic-concentration/
├── siar-economic-health/
├── siar-payout/
├── siar-economic-observability/
└── siar-economic-testkit/
289. siar-economics-core
Owns:
economic types
amounts
periods
errors
290. siar-operator-cost
Cost classes/models.
291. siar-compensation
Settlement/payout calculation.
292. siar-subsidy
Programs/claims/decisions.
293. siar-reserve
Reserve draw/replenishment.
294. siar-economic-policy
Signed compensation/subsidy policy.
295. siar-economic-concentration
Operator concentration analysis.
296. siar-economic-health
Network sustainability state.
297. siar-payout
External payout adapters.
298. siar-economic-observability
Privacy-safe financial health metrics.
299. siar-economic-testkit
Economic attack/sustainability simulator.
300. Error Taxonomy
#![allow(unused)] fn main() { pub enum EconomicError { SettlementDuplicate, ReceiptInvalid, SubsidyBudgetExceeded, ClaimInvalid, OperatorIneligible, ReserveInsufficient, PolicyMismatch, PriceInvalid, PayoutFailed, ArithmeticOverflow, Internal, } }
301. Security & Economic Invariants
Mandatory:
1. Operator compensation never requires user identity or social-graph data.
2. Routing/provider eligibility is not increased because an operator pays more or receives sponsorship.
3. No packet-level payment identity exists inside anonymous routing.
4. Subsidies are based on verified aggregate service/capacity evidence, not raw user records.
5. Operator payout identity is isolated from provider runtime identity.
6. Economic state cannot weaken privacy/security policy.
7. Economic disputes do not automatically become network revocation decisions.
8. Subsidy and settlement processing are idempotent and budget-bounded.
9. No speculative token or stake is required for SIAR governance.
10. Financial audit data remains separate from user traffic telemetry.
11. Concentration caps prevent one operator from capturing excessive subsidy/compensation share where policy requires.
12. Network underfunding degrades capacity/features, never silently anonymity.
302. Initial Production Scope
Implement first:
service-usage settlement
aggregate operator payouts
fixed compensation policy
public-good subsidy programs
capacity reserve subsidy
network reserve fund
operator diversity/concentration monitoring
signed economic policies
privacy-safe economic metrics
deterministic settlement engine
Then add:
advanced independent capacity verification
multi-funder subsidy pools
cross-domain settlement
formal economic simulations
privacy-preserving operator grant mechanisms
303. Definition of Done
Part 54 is complete when:
- real operator cost classes are explicit
- direct usage revenue, grants, subsidy, reserve, and public-good funding are separated
- operator compensation uses aggregate signed receipts
- no user identity is required for operator payout
- routing/provider selection is economically neutral
- public-good and censorship-resistance subsidies are defined
- reserve capacity and disaster support are fundable
- subsidy Sybil/fake-capacity/wash-usage attacks are addressed
- operator concentration and sustainability are monitored
- governance controls economic policy, but economics cannot override privacy floors
- financial/tax identity remains at settlement boundary
- exact arithmetic and settlement idempotency are required
- economic shocks cause capacity/pricing changes, not privacy downgrade
- sustainability, concentration, fraud, fuzz, and formal tests are specified
304. Final Architecture
USER / ORG FUNDING
│
▼
CREDIT / REVENUE
│
▼
SERVICE USAGE RECEIPTS
│
▼
AGGREGATE SETTLEMENT
│
┌───────────────┼───────────────┐
│ │ │
Operator Pay Subsidy Pool Reserve Fund
│ │ │
└───────────────┼───────────────┘
▼
SUSTAINABLE INFRASTRUCTURE
Economic safety model:
real cost
+
transparent price
+
aggregate receipts
+
operator compensation
+
subsidy
+
reserve
+
anti-concentration controls
not:
token speculation
+
pay-to-route
+
user-level payout tracking
305. Final Principle
Economic sustainability is necessary for anonymity infrastructure, but economics must remain subordinate to privacy, diversity, and security.
The correct model is:
usage-based revenue
+
public-good subsidy
+
operator sustainability
+
aggregate privacy-preserving settlement
+
anti-centralization incentives
without making identity, routing, or governance dependent on wealth.
This architecture gives SIAR a viable path to fund long-lived anonymous infrastructure while preserving the privacy, operator-diversity, and governance guarantees established across Parts 34–53.