Economics

Design decisions pending. The current pricing model is a placeholder — flat resource rates, scaled only by a per-provider price multiplier that is itself simulation-only. There is no performance weighting. The target model introduces a performance-based value coefficient. See Future: Performance-Based Pricing for the planned direction.

Lease pricing is deterministic and computed on-chain from three resource dimensions (vCPUs, memory, disk), the duration, and the price multiplier carried by the provider's performance certificate. All nodes independently compute the same cost and reject blocks that don't match. Apart from the certificate multiplier, there is no negotiation on price — the rates are protocol constants.

The XE emission is not the same number as the XUSD cost: it scales the cost by the emission rate R locked onto the lease when the provider accepted it.

Constants

Defined in core/ledger.go:

Constant

Value

Unit

LeaseVCPURate

20,000

micro-XUSD per vCPU per hour

LeaseMemGBRate

10,000

micro-XUSD per GB memory per hour

LeaseDiskGBRate

1,000

micro-XUSD per GB disk per hour

LeaseStakeDivisor

stake = ceil(cost / 5), minimum 1 µXUSD

LeaseMaxDuration

31,536,000

seconds (365 days)

Lease timings are genesis-pinned network parameters rather than constants (#524). The production defaults are:

Parameter

Production default

Meaning

LeaseMinDuration

60 s

minimum lease duration

LeaseSettleGrace

1 h

expiry → end of the provider's settle window

LeaseForceSettleGap

25 min

dead zone before the consumer's force-settle window opens

LeaseEscrowExpiry

365 d

expiry → escrow burn deadline

LeaseArchiveGap

1 h

local GC delay past the consensus deadline

MaxAttestationSkew

10 min

allowed attestation clock skew

[!IMPORTANT] Read timings from the network, not from this page A network pins these at genesis, so a compressed test network runs on different numbers with the same binary. GET /node returns the live values under lease_timing.

Cost Calculation

hours        = ceil(duration_seconds / 3600)
memGB        = ceil(memory_mb / 1024)
perHourMicro = (vcpus × 20_000) + (memGB × 10_000) + (diskGB × 1_000)
costMicro    = perHourMicro × hours
cost         = max(1, ceil(costMicro × multiplierMilli / 1000))

Everything is integer arithmetic in micro-XUSD; multiplierMilli is the certificate price multiplier scaled ×1000 (1000 = 1.000×).

Example: 2 vCPUs, 2048 MB memory, 10 GB disk, 3600 seconds (1 hour) at 1.000×: - perHourMicro = (2×20,000) + (2×10,000) + (10×1,000) = 40,000 + 20,000 + 10,000 = 70,000 - costMicro = 70,000 × 1 = 70,000 - cost = 70,000 µXUSD = 0.07 XUSD

Example: 4 vCPUs, 8192 MB memory, 100 GB disk, 720 hours (30 days) at 1.000×: - perHourMicro = (4×20,000) + (8×10,000) + (100×1,000) = 80,000 + 80,000 + 100,000 = 260,000 - costMicro = 260,000 × 720 = 187,200,000 - cost = 187,200,000 µXUSD = 187.2 XUSD

Denomination

All on-chain amounts are unsigned 64-bit integers of micro-units. Both assets carry 6 decimal places: 1 XE = 1,000,000 µXE, 1 XUSD = 1,000,000 µXUSD. Amounts are plain JSON numbers on the wire, never strings.

Token

On-chain representation

Notes

XUSD

micro-XUSD (uint64, 6 dp)

Payment token; escrowed on lease, burned on settlement

micro-XE (uint64, 6 dp)

Emission token, minted on settlement

Money Flow

Consumer                          Provider
────────                          ────────
                    lease block
  XUSD balance -= cost  ─────────────────►  (escrow pending send created)

                    lease_accept block
                    ◄─────────────────────  XUSD balance -= stake
                                            (escrow stays alive)

                    lease_settle block
                    ◄─────────────────────  XE balance += emission (minted)
                                            XUSD balance += stake (returned)
                                            escrow deleted = consumer XUSD burned

Consumer: Pays cost XUSD into escrow. The escrow survives acceptance and is burned only when the provider settles. If the lease is cancelled before acceptance, or force-settled after the provider abandons it, the escrow is refunded in full.

Provider: Stakes ceil(cost / 5) XUSD (min 1 µXUSD) on acceptance. On settlement within the grace window the stake is returned and emission XE is minted. The provider earns XE from nothing — it is newly created supply.

Net effect: XUSD is deflationary (burned on every settled lease). XE is inflationary (minted on every settlement). The two tokens serve different purposes: XUSD for payment, XE for economic incentive and delegated vote weight.

Stake

The provider must lock ceil(cost / LeaseStakeDivisor) (⌈cost ÷ 5⌉, minimum 1 µXUSD) when accepting a lease. This creates a disincentive against accepting leases without providing compute — the stake is only returned on valid settlement inside the settle window.

Griefing (core#113, addressed by force-settle): a provider that accepts a lease and never settles no longer keeps the consumer's money. Once expiry + LeaseSettleGrace + LeaseForceSettleGap has passed, the consumer submits a lease_force_settle that refunds their full escrowed cost and leaves the provider's stake burned, marking the lease unfulfilled and recording it against the provider's reputation. If both parties are offline, the refund window closes at expiry + LeaseEscrowExpiry; each node then burns the escrow locally once a further LeaseArchiveGap has passed, marking the lease expired.

XE Emission

Settlement mints XE, it does not transfer it. The amount is derived from the lease cost and the emission rate:

R_capped = CapR(LockedR, LockedPayoutCap, LockedTWAP)
emission = max(1, ceil(cost × R_capped / 1000))     // micro-XE

LockedR is R_effective scaled ×1000, captured onto the lease at lease_accept time from the epoch covering the attested accept timestamp. It must be carried in the signed accept block — there is no fallback to whatever epoch is live at settle time, so every node computes the same emission.
CapR applies the payout cap: min(R, payoutCap × 1000 / twapMilliUSD). A zero cap or zero TWAP disables it.
The product is overflow-checked; an overflowing emission is rejected rather than minted.

[!NOTE] Where the rate comes from R_effective, the payout cap and the TWAP are token-economics parameters published per epoch by the oracle onto the state chain. The lease code only consumes them. This page deliberately quotes no numbers for the R curve — see the XE token economy model for the curve itself.

Attestations (Timestamps)

Both lease_accept and lease_settle blocks require timekeeper attestations — signed timestamps from trusted third parties. lease_force_settle requires them too. This prevents providers from faking timestamps to settle early, and consumers from force-settling early.

Minimum attestations: configurable threshold (from TimekeeperConfig)
Maximum per block: 20 (MaxAttestationsPerBlock)
Maximum skew: ±MaxAttestationSkew from current time — genesis-pinned, production default 10 minutes
Settlement check: attested median must be ≥ startTime + duration and ≤ expiry + LeaseSettleGrace (in nanoseconds)
Force-settle check: attested median must be ≥ expiry + LeaseSettleGrace + LeaseForceSettleGap and < expiry + LeaseEscrowExpiry

LeaseForceSettleGap is required to exceed 2 × MaxAttestationSkew — validated against the genesis-pinned value — so no single real timestamp, even shifted by the maximum skew at each end, can satisfy both the settle and the force-settle window.

Known issue (core#44): for short leases, the attestation skew window leaves room for settlement earlier than the nominal duration. Needs design review.

Where the Code Lives

Component

File

Symbol

Constants

core/ledger.go

LeaseVCPURate, LeaseMemGBRate, LeaseDiskGBRate, LeaseStakeDivisor

Genesis-pinned timings

core/ledger.go

ApplyGenesisLeaseTiming

Cost / stake / emission

core/ledger.go

LeaseCost, LeaseStake, CapR, LeaseEmissionChecked

Overflow / rounding helpers

core/ledger.go

safeMul, ceilDiv

Lease block validation

core/ledger.go

validateAndAddLease

Lease accept validation (stake, locked R)

core/ledger.go

validateAndAddLeaseAccept

Lease settle validation (emission, stake return)

core/ledger.go

validateAndAddLeaseSettle

Cancel and force-settle validation

core/ledger.go

validateAndAddLeaseCancel, validateAndAddLeaseForceSettle

Marketplace offer with cost

node/node.go

handleMarketplace

Consumer lease block creation

node/node.go

CreateLeaseBlock

Settle / force-settle / archive sweeps

node/node.go

settleLoop

Attestation validation

core/attestation.go

ValidateAttestations

Problems with the Current Model

1. No performance differentiation

All vCPUs are priced identically. A provider running a high-end server with fast NVMe and a provider running a Raspberry Pi charge the same rate. There is no incentive to provide quality compute.

2. Base rates are protocol constants

The base rates (20,000 / 10,000 / 1,000 µXUSD) are hardcoded; changing them requires a protocol update across all nodes. A provider can scale its own rate with the certificate price multiplier (#297), but that is a simulation-only lever today: non-baseline multipliers are gated on the anti-cheat work in #213/#214/#215, and the node logs a warning when it issues a certificate with one. There is still no market-driven price discovery.

3. Emission is not decoupled from resource dimensions

Emission is cost × R_capped, so it tracks the cost formula directly. R (and the payout cap) is an independent supply-side lever set per epoch by the oracle, but there is no per-lease quality term: if costs go up to reflect quality, emissions go up proportionally.

4. No accountability for uptime or quality

The provider earns the full emission regardless of actual compute quality, uptime, or availability during the lease. The only check is that enough time passed.

5. Stake-to-escrow ratio

The stake is ⌈cost/5⌉, so a provider risks roughly a fifth of what the consumer escrows. Force-settle now refunds the consumer rather than leaving them out of pocket, but the provider's downside for abandoning a lease is still only the stake plus the reputation record.

Future: Performance-Based Pricing

A first piece of this already exists: performance certificates carry a PriceMultiplierMilli that the ledger uses when validating lease cost, so the plumbing for per-provider pricing is in place. What is missing is deriving that multiplier from a trustworthy performance measurement.

The target model replaces flat resource rates with a performance-derived value:

performance_score × time = lifetime_value
xusd_cost  = lifetime_value × cost_coefficient
xe_emission = lifetime_value × emission_coefficient

Performance Score

The performance score captures the actual capability of the resources being leased, not just their nominal specification. A 4-vCPU machine with fast cores on NVMe storage should score higher than 4 vCPUs on a slow host.

Open questions:

How is performance measured? Options include:
Benchmark on provision (run a standard benchmark suite when the VM starts)
Self-reported by provider (requires verification mechanism)
Measured by consumer workload (too variable, hard to standardize)
Proof-of-uptime heartbeat with embedded micro-benchmarks
What dimensions contribute? At minimum:
CPU throughput (single-core and multi-core)
Memory bandwidth
Disk IOPS and throughput
Network latency and bandwidth (to other nodes)

How does it compose with resources? A machine with 4 high-performance vCPUs is worth more than 4 low-performance vCPUs, but it also needs to account for memory and disk:

raw_performance = benchmark_score(cpu, memory, disk, network)
resource_weight = f(vcpus, memory_gb, disk_gb)  // scaling factor
performance_score = raw_performance × resource_weight

Who runs the benchmark? If the provider benchmarks themselves, they could inflate scores. If the consumer runs it, they could deflate. A neutral party (timekeeper? sentinel node?) may be needed.
How often is it measured? Once at provider registration? Per lease? Continuously? There's a tradeoff between accuracy and overhead.

Lifetime Value

lifetime_value = performance_score × duration_hours

This represents the total compute value delivered. A fast machine running for 1 hour has the same lifetime value as a machine half as fast running for 2 hours (assuming similar resources).

Cost and Emission Coefficients

Two independent coefficients decouple XUSD cost from XE emission:

xusd_cost       = lifetime_value × cost_coefficient
xe_emission     = lifetime_value × emission_coefficient

cost_coefficient: Controls how expensive compute is in XUSD. Could be a governance parameter on the state chain.
emission_coefficient: Controls XE inflation rate independently of pricing. Could decrease over time (halving schedule, decay curve) to control long-term supply.

Open questions:

Who sets the coefficients? Options:
Protocol constants (like today, but with two levers)
DAO governance via state chain
Market-driven (providers set prices, protocol sets emission)
Should cost be market-determined? Providers could set their own prices (competing on price×performance), with the protocol only governing emission rates. This would allow natural price discovery.
How to handle the stake? Current model stakes ceil(cost / 5). With performance-based pricing, the stake could be tied to the performance claim — higher claimed performance requires higher stake, penalizing inflated benchmarks.

Transition Plan

The migration from flat rates to performance-based pricing requires:

Benchmarking infrastructure: A standard benchmark suite that runs on provisioned VMs and produces a reproducible score.
Score attestation: A mechanism to verify benchmark results (possibly integrated with proof-of-uptime heartbeats).
Coefficient governance: A way to set and update cost/emission coefficients (likely via state chain DAO operations).
Protocol versioning: Existing leases created under flat rates must still validate. New leases would use the performance model. The validation code needs to handle both.
Marketplace update: Resource offers would include a performance score and derived cost, not just raw resource dimensions.

Impact on Existing Components

Component

Change Needed

LeaseCost()

Replace with LifetimeValue() × coefficient

Lease block

Add performance_score field

Marketplace offers

Include benchmark score

Provider registration

Run benchmark, publish score

Attestation system

Possibly attest benchmark results

State chain

Store coefficients as governance parameters

Settlement validation

Verify performance score was legitimate

Proof-of-uptime

Integrate micro-benchmarks into heartbeats

Explorer / wallet

Display performance scores and derived costs