Version
v0.1 (Revenue Model Draft)
How money is generated and distributed in the system
This page defines HolyCode commercial mechanics: where revenue comes from beyond investments, who pays, how payments are settled, how fiat is converted into the crypto layer, how physical data-center infrastructure operates, and how creators are paid.
Version
v0.1 (Revenue Model Draft)
Publication Date
March 5, 2026
Status
Hybrid Software + Infrastructure Revenue Framework
Users do not pay for a raw model; they pay for trained role context and measurable execution outcomes. HolyAgent stores role memory, connects any LLM provider, and produces repeatable output monetized via marketplace, runtime usage, and managed hosting on HolyCode infrastructure.
Beyond DAO investment inflows
| Stream | Revenue Source | Who Pays | Settlement Basis |
|---|---|---|---|
| Role Marketplace Sales | Paid access to published roles | Users/teams | Fixed-price or token-based access |
| Automation Usage | HolyAgent runtime execution fees | B2B and individual users | Per run, per hour, or usage tier |
| Result-Based Contracts | Payment for achieved KPI/result | Outcome-contract clients | By accepted outcome |
| Revenue Share Roles | Percentage of client sales | Client via revenue split | Per reporting sales cycle |
| HolyBuild Delivery | Task execution and delivery fees | Development/automation customers | Milestone, retainer, or per-task |
| HolyDC Agent Hosting | Leasing agents and compute capacity in HolyCode data centers | B2B/B2G clients and DAO members | Subscription, reserved capacity, or metered compute usage |
Data centers as a dedicated business layer
How clients lease agents and compute in HolyDC
| Product | Capacity Footprint | Best For | Pricing Model |
|---|---|---|---|
| Shared Agent Cloud | Shared HolyDC pool with usage limits | Startups, small teams, pilots | Subscription + pay-as-you-go overage |
| Dedicated Agent Pod | Dedicated pod/GPU pool per client | B2B teams with sustained load | Monthly reserved-capacity contract |
| Private Agent Cluster | Isolated HolyDC cluster with custom SLA | Enterprise/B2G and compliance-sensitive workloads | Annual contract + setup fee |
Train once, monetize repeatedly
| Model | Billing Method | Buyer Segment | Creator Payout |
|---|---|---|---|
| Fixed | One-time access fee | Teams and individuals | After payment confirmation |
| Hourly | Runtime-hour billing | Operational teams | Periodic (daily/weekly) |
| Token Usage | Token payment per run | DAO and external users | Auto from usage pool |
| Result-Based | Payment per KPI result | B2B clients | After acceptance |
| Revenue Share | Percentage of generated sales | Sales-driven clients | Per revenue-settlement cycle |
Fiat -> Stable -> Token -> Payout
Can be updated via DAO voting
| Bucket | Share | Purpose |
|---|---|---|
| Role Creator | 70% | Creator income and role quality maintenance |
| DAO Treasury | 20% | Product growth and operational funding |
| AI-Agent Reserve | 10% | Incentives, R&D, and execution-layer resilience |
Scenario model for revenue, payouts, and margin across role economy and HolyDC hosting.
Model Assumptions
This business plan defines target economic mechanics and may evolve with product scale, compliance requirements, and DAO decisions. Governance rules are defined separately in the Manifesto.