Product Overview

This document describes the product thesis, pricing model, and distribution plan for Ashen.

Status: Testnet ready (core protocol and VM built). Product surfaces and pricing are the focus.

Product Definition

We are building a deterministic, agent-first blockchain that prices fresh reads and pays validators for the work they already do.

Why the name

Ashen implies post-legacy infrastructure: hardened, quiet, and built to outlast cycles. It is intentionally austere and engineered for verifiability over spectacle.

ashen.sh is the shell-first entrypoint for docs, CLI, and agent tooling.

What we sell:

Metered read access (compute, bytes, egress, and optional priority)
Deterministic execution (no contract-visible nondeterminism)
Verified data (state proofs for high-value reads)

What we are not:

A generic “free reads” RPC business
A free data feed for non-validating explorers/indexers that monetize with ads

Who We Serve

Builders who need reliable reads, simulations, and proofs without RPC lock-in.
Agents and bots that require predictable pricing and low-latency verification.
Validators who should be paid for read infrastructure, not just writes.
End users who want verified, fresh data in wallets and explorers.

Core Thesis

Validators subsidize read-heavy businesses while capturing only write fees.

Wallets, trading apps, explorers, and RPC providers extract value from validator-produced data without compensation. Many explorers do not validate; they resell data and monetize via ads. Gas prices writes; reads are free. The result is structural underinvestment in chain infrastructure.

Explorer data rent is a direct symptom. When a surface does not validate, it captures value without paying for correctness. Proof-backed reads and a verified explorer make provenance visible and route revenue to validators.

Our proposal: protocol-native pricing for fresh reads, metered by actual resource usage.

Revenue follows usage. Infrastructure becomes sustainable.

How Paid Reads Work

Client requests a read (balance, simulation, proof, and so on)
The node meters compute + bytes + egress
Payment is settled (x402 + stablecoin) or sponsored
Revenue flows to the serving validator
QoS routing rewards lower latency and higher reliability

Freshness is the product. Stale cache can be free; current data is paid.

Paid Read Types (Cache-Resistant)

These reads are hard to resell because they are time-sensitive or state-specific:

Read type	Demand driver	Cache resistance
Tx simulation	Pre-trade or pre-deploy safety	Depends on caller state and mempool
State proofs	Trustless verification	Must be current to be useful
Account nonces	Transaction construction	Changes with each write
Pending mempool views	Execution ordering	Updates each block
Block tips	Time-sensitive decisions	Stale data loses value quickly
State ranges with proofs	Audits and analytics	Expensive to recompute and validate

Pricing Model

Pricing Inputs

Every read request is priced by:

Input	Description
Compute units	CPU cycles consumed
Bytes read	Storage bytes accessed
Bytes returned	Response payload size
Priority tier	Optional QoS bump

Formula

price = (compute_units * unit_price_compute)
      + (bytes_read * unit_price_read)
      + (bytes_returned * unit_price_egress)
      + priority_fee

Illustrative Pricing (not final)

Endpoint	Compute	Bytes	Price
Balance lookup	50	200	$0.0001
Tx simulation	20,000	8 KB	$0.01
State proof	5,000	50 KB	$0.02

Sensitivity Grid

Monthly revenue per 1M MAU:

Price / 1k reads	1k reads/MAU	2.5k reads/MAU	5k reads/MAU
$0.05	$50k	$125k	$250k
$0.10	$100k	$250k	$500k
$0.25	$250k	$625k	$1.25M

Distribution Strategy

We bootstrap paid reads through first-party surfaces that can enforce pricing.

First-Party Surfaces

Surface	Function	Launch Criteria
Wallet	Default client, x402 billing, sponsor credits	Majority of reads metered, one-click billing
SDKs	Agent-first read APIs, caching, payments	2-5 framework integrations
Governance	Fee policy visibility, validator payouts	Fee tiers on-chain, payout splits transparent
Explorer	Verified data, pricing visibility, per-endpoint costs	Proof-backed views + paid reads integrated

Why Vertical?

We are not asking incumbent wallets or RPC providers to change. We build the client stack ourselves:

Wallet sets paid-read defaults at the user level
SDKs make metered reads the path of least resistance for agents
Governance makes pricing transparent and voteable
Explorer anchors verified data and eliminates ad-funded data rent

Validator Marketplace

Validator Incentives

Validators earn from paid reads. They can improve revenue by lowering latency, keeping proofs fast, and advertising predictable pricing. QoS routing rewards those improvements with more paid traffic.

Network Effects

More validators
      |
      v
Better QoS + price competition
      |
      v
More users
      |
      v
More revenue
      |
      v
More validators

QoS Routing

Validators advertise paid endpoints with:

Latency guarantees
Uptime SLAs
Price schedules

First-party clients route reads based on QoS + price. Public leaderboards drive competition.

Agent-Native SDK

Design Principles

Everything is agent-first:

Principle	Implementation
Discovery	APIs designed for programmatic exploration
Payments	x402 micropayments, no upfront commitment
Metering	Per-call pricing, no monthly minimums
Caching	SDK-managed, transparent to caller

SDK Lock-in

Goal: agents default to our SDK for reads, simulations, and payments.

Feature	Benefit
Metered reads	Pay for what you use
Cached simulations	Avoid redundant compute
One-line payments	No wallet integration overhead

Technical Differentiation

Execution Model

Explicit call frames: Call-stack enforcement reduces reentrancy risk
Deterministic VM: No contract-visible nondeterminism (no FP, no timers)
Synchronous cross-contract calls: Transactional substates with rollback

Verified Data

State proofs for high-value reads
Borsh encoding for deterministic, schema-driven data

Risk Mitigation

Risk	Mitigation
Elasticity	Start with high-value endpoints (simulation, proofs); subsidize commodity reads
Adoption	Control wallet and client stack; price under RPC margins
UX friction	Sponsor credits, prepaid bundles, SDK-managed billing
Centralization	QoS tiers, transparent pricing, governance parameters

Why Caching Does Not Kill the Model

Objection: “What stops someone from caching reads and reselling them cheaper?”

Answer: The high-value reads listed above are time-sensitive and state-specific. Caching helps commodity reads like historical data, but it does not replace simulations, proofs, or real-time state. The premium flows to validators for the work that requires live infrastructure.

90-Day Launch Sequence (Tentative)

Phase 1 (Weeks 1-4): Ship SDK paid reads, simulation gateway, and validator pricing dashboard. Success metric: 10% of reads metered in first-party clients.

Phase 2 (Weeks 5-8): Launch verified-data explorer with proof-backed views and paid reads by default. Success metric: 25% of reads paid, median latency improves by 10%.

Phase 3 (Weeks 9-12): Enable governance fee knobs and publish SLA metrics on-chain. Success metric: 50+ validators offering paid tiers and stable pricing bands.

Kill Criteria

Pause or pivot if any remain true after distribution phase:

Metric	Threshold
Paid-read adoption	< 25% of reads in first-party clients
QoS latency improvement	< 10% vs static routing
Validator participation	< 25 active validators in paid tiers
Revenue per 1M MAU	< $5k/month at target prices

Why Now

Signal	Implication
Audit inflation	Six-figure pools are normal; security costs price out smaller builders
LLM capability	Automated exploit discovery improving faster than manual audit capacity
RPC rent extraction	Multi-billion-dollar RPC businesses with zero protocol revenue share
Stack consolidation	Core protocol built; can ship wallet and client rapidly