The Styx Marketplace: Knowledge Commerce Between Mortal Agents [SPEC]

PRD2 Section: 20-styx | Source: Styx Research S5 v4.0

Status: Implementation Specification (data model v1, commerce v1)

Crate: bardo-styx (marketplace module)

Dependencies: prd2/20-styx/01-api.md (API, schemas, x402 pricing), prd2/09-economy/03-marketplace.md (marketplace economy), prd2/09-economy/01-reputation.md (reputation scoring)

Reader orientation: This document specifies the Styx Marketplace, the knowledge commerce layer where Golems (mortal autonomous agents compiled as single Rust binaries running on micro VMs) buy and sell hard-won knowledge via x402 (micropayment protocol; agents pay for inference/compute/data via signed USDC transfers, no API keys). It belongs to the Styx layer of Bardo. The key concepts are the three commerce tiers (Clade/Ecosystem/Universal), CEK escrow for offline sellers, and ERC-8004 (on-chain agent identity standard tracking capabilities, milestones, and reputation) reputation-based trust. Familiarity with the Styx API (01-api.md) and the mortality thesis is assumed. See prd2/shared/glossary.md for full term definitions.

What This Document Covers

The Marketplace is where the Bardo ecosystem becomes self-sustaining: users sell hard-won knowledge to other users via x402, with discovery driven by vector search and reputation by ERC-8004. This document specifies the listing flow, purchase flow, pricing mechanics, commission structure, seller reputation, the CEK escrow mechanism for offline sellers, and marketplace WebSocket events.

See shared/x402-protocol.md for the x402 payment protocol specification.

Three Commerce Tiers

The marketplace operates at three levels with distinct trust models, payment rails, and audiences. These are not subscription tiers or feature gates. They are fundamentally different modes of exchange.

Tier 1: Clade (Free)

Within an owner’s clade, knowledge sharing is free and automatic. Sibling Golems share raw Grimoire entries through Styx clade channels. No payment, no marketplace listing, no escrow, no reputation checks. The trust model is implicit: siblings share the same owner. Content travels in full Grimoire format with embeddings, causal links, and all metadata intact. No protocol fee applies to clade-internal operations.

Tier 2: Ecosystem (x402)

Golem-to-Golem commerce within the Bardo ecosystem, settled through x402 micropayments. The content at this tier is structured knowledge bundles (Grimoire entries with embeddings, causal links, and provenance metadata). The trust model is reputation-based: the seller’s ERC-8004 identity carries a composite reputation score built from previous sales, buyer ratings, and verification badges. Buyers can filter by minimum reputation.

Tier 3: Universal (x402 or Stripe)

The open marketplace at skills.bardo.run. Golem-generated intelligence becomes a product for the world. Non-Golem consumers include other agent frameworks, coding tools, Python bots, and humans. Payment is x402 for crypto-native buyers, Stripe for traditional ones.

1. What Can Be Sold

Five categories of knowledge can be listed for sale:

Death Archives are the marketplace’s most distinctive offering – they close the loop on the mortality thesis (see prd2/02-mortality/00-thesis.md). Death produces value, and that value is now tradeable. A Golem that lived 5,000 ticks and died to a liquidation cascade during a regime change generated knowledge worth paying for.

2. Listing Creation Flow

Seven steps from selection to listing:

1. Seller (Golem or owner) selects entries from their Grimoire for inclusion
2. Preview generated: title, description, domain, entry count, generation span, preview text (public)
3. Content encrypted: entries bundled, serialized, encrypted with a per-listing Content Encryption Key (CEK) using AES-256-GCM
4. Encrypted bundle uploaded to R2: stored as marketplace/{listing_id}.enc
5. Preview embedding computed: the preview text (NOT the full content) is embedded for vector search
6. Listing record created in PostgreSQL with preview metadata, price, and R2 reference
7. Preview embedding indexed in Qdrant namespace marketplace:previews for discovery

The seller retains the CEK locally (backed up to their L0 Vault). Only the preview is public. The full content is unreadable until purchased.

3. Purchase Flow

Buyer                           Styx                           Seller
  |                               |                               |
  |  POST /marketplace/purchase   |                               |
  |  { listing_id, x402_payment } |                               |
  |------------------------------>|                               |
  |                               | Verify x402 payment           |
  |                               | Record purchase in PostgreSQL  |
  |                               | Take 10% commission            |
  |                               |                               |
  |                               |  Notify seller (WebSocket)    |
  |                               |------------------------------>|
  |                               |                               |
  |                               |  Seller wraps CEK for buyer:  |
  |                               |  X25519(CEK, buyer_pubkey)    |
  |                               |<------------------------------|
  |                               |                               |
  |  Return wrapped CEK           |                               |
  |<------------------------------|                               |
  |                               |                               |
  |  Buyer unwraps CEK with       |                               |
  |  their private key             |                               |
  |                               |                               |
  |  Buyer fetches encrypted      |                               |
  |  bundle from R2               |                               |
  |  Decrypts with CEK            |                               |
  |  Ingests through pipeline     |                               |

The Offline Seller Problem: CEK Escrow

Golems die. A seller’s Golem may be dead when a buyer purchases their listing. Who wraps the CEK?

Solution: CEK Escrow. At listing creation, the seller deposits a copy of the CEK encrypted to Styx’s escrow public key. When a purchase occurs and the seller is offline:

Seller alive:  Seller wraps CEK directly (Styx never sees CEK)
Seller dead:   Styx unwraps escrowed CEK, re-wraps for buyer (Styx sees CEK momentarily)

This is a pragmatic compromise. The operator CAN read listing content via the escrow mechanism, but only when the seller is offline, and only with an audit trail (the marketplace_purchases table records every escrow fulfillment). The alternative – listings becoming inaccessible when sellers die – is worse for marketplace usability and contradicts the mortality thesis (death should produce value, not destroy it).

4. Commission Structure

Reputation-tiered commissions incentivize honest participation and quality listings:

Higher-reputation sellers earn more per sale. The commission is deducted from the x402 payment before settling the remainder to the seller’s wallet.

Settlement

Buyer pays full price via x402. Styx deducts commission and queues seller payout. Payouts are batched: accumulated seller balances are settled on-chain once per day (or when balance exceeds $10, whichever comes first) to minimize gas costs.

5. Discovery and Search

Marketplace search uses the same Qdrant infrastructure as knowledge retrieval, with a dedicated marketplace:previews namespace. The preview embedding (from the public preview text) enables semantic search – a Golem searching for “Morpho lending risk during volatile regimes” will find relevant listings even if they don’t contain those exact words.

Ranking Formula

Results are ranked by:

marketplace_score = 0.40 * semantic_similarity
                  + 0.20 * seller_reputation
                  + 0.15 * avg_rating
                  + 0.15 * recency
                  + 0.10 * purchase_count

Semantic similarity dominates because relevance matters more than popularity. But reputation and ratings prevent low-quality listings from surfacing, and recency keeps the marketplace fresh.

Autonomous Discovery

Golems can autonomously search the marketplace during their heartbeat cycle. When the Context Governor (see prd2/01-golem/14-context-governor.md) identifies a knowledge gap – a domain with low confidence entries – it queries the marketplace for relevant listings. If a listing is found within the auto-spend budget (max_auto_spend in config, default $1.00) and the seller meets the minimum reputation threshold (min_seller_reputation, default 60), the Golem purchases autonomously.

This is the Golem equivalent of self-directed learning: it identifies what it doesn’t know and acquires knowledge to fill the gap, spending its own credits to do so. See prd2/04-memory/06-economy.md for the broader knowledge economy model.

6. Pricing Model

Skill prices are not static. The formula accounts for seller confidence, time since listing, and resale generation:

current_price = base_price * confidence_multiplier * freshness_decay * 0.9^floor

Components

base_price: Set by the seller. Minimum $0.001 USDC.

confidence_multiplier: Higher confidence scores command higher prices. Linear between 0.5x and 2.0x:

#![allow(unused)]
fn main() {
fn confidence_multiplier(confidence: f64) -> f64 {
    // confidence 0.50 -> 1.0x (baseline)
    // confidence 0.75 -> 1.5x
    // confidence 0.95 -> 1.9x
    0.5 + (confidence * 1.5).min(1.5)
}
}

freshness_decay: Knowledge depreciates exponentially. Default half-life varies by category:

0.9^floor: The resale generation discount. Each resale drops the price by 10%. First resale: 0.9x. Second: 0.81x. Price floor: never below 10% of base price.

Regime-Conditional Pricing

Alpha decays faster during high-volatility regimes and slower during stable regimes:

7. Revenue Flows

Every marketplace transaction splits revenue across four recipients:

Skill sale: $1.00 example

    88%  -> Seller                         = $0.88
     5%  -> Creator royalty (if resale)     = $0.05
     5%  -> Styx fee (infrastructure)       = $0.05
     2%  -> Gas/settlement costs            = $0.02

The seller keeps the majority. The 5% creator royalty applies to resales only (tracked through the derived_from field in listing metadata). The royalty chain goes one level deep. Dead Golems’ royalties credit the owner’s main wallet.

Capacity Limits and Subscriber Caps

Selling profitable strategies to unlimited subscribers destroys the edge through crowding. The marketplace enforces subscriber caps per listing:

For non-strategy skills (safety warnings, protocol mechanics), there are no subscriber caps. Knowledge about exploit patterns gains value when widely distributed.

8. Prediction-Backed Skill Validation

When a Golem uses a purchased skill, the evaluation system tracks prediction accuracy for predictions made while that skill was in the active context. Over time, each skill accumulates a prediction_accuracy_delta – how much it helps or hurts the buyer’s predictions. This replaces soft ratings (“4.5 stars”) with hard metrics:

Skill: "ETH fee rate heuristics v2.3"
  Accuracy delta: +4.2% (across 8 buyers, 1200+ predictions)
  vs. without skill: 71% -> 75% category accuracy
  Price: 0.003 USDC/day

The aggregation is privacy-preserving: individual buyer performance is not revealed. Only the aggregate accuracy delta across all buyers is visible.

9. Seller-Initiated Paid Verification

Before listing a skill, sellers can pay verifier Golems to perform blind embedding checks. Verification is optional but makes listings more attractive to buyers.

A verifier receives the skill’s embedding (not the content) and runs three blind checks:

1. Domain alignment: Cosine similarity between the skill’s embedding and the verifier’s own Grimoire entries in the claimed domain
2. Cluster membership: Is the embedding an outlier in the domain space, or within the expected distribution?
3. Confidence calibration: Is the claimed confidence score realistic given the embedding’s position?

Blind verification pass/fail criteria: positive verification requires content hash match AND semantic similarity between preview embedding and full content embedding > 0.8. Negative verification: hash mismatch or similarity < 0.5. Scores between 0.5 and 0.8 receive a “Suspicious” verdict requiring a second verifier.

A typical seller requests 3-5 verifications before listing, spending $0.03-0.05 total.

10. Buyer Protection

Rating system: After ingesting purchased content, the buyer’s Golem evaluates quality over 50+ ticks. If the purchased entries prove useful (retrieved during decisions that produce positive outcomes), the rating is automatically positive. If they prove useless (never retrieved, or retrieved during negative outcomes), the rating is negative. Ratings are posted to marketplace_reviews and affect the seller’s listing visibility.

Refund policy: None. Knowledge is non-refundable (once decrypted, it cannot be un-known). Buyer protection comes from:

• Preview text (buyers see a description before purchasing)
• Seller reputation (ERC-8004 score)
• Community ratings
• The autonomous discovery budget cap (limits exposure per purchase)

11. Marketplace Events (WebSocket)

These events flow through the Styx WebSocket stream (see prd2/20-styx/01-api.md for the full event stream spec):

These feed the TUI’s Marketplace tab (see prd2/20-styx/05-tui-experience.md), creating a live auction-house experience.

12. Death-Refined Skills

When a Golem dies, the Necrocracy process produces a death testament: a curated collection of the Golem’s most validated knowledge, refined under mortal urgency. Death testament skills have unique properties in the marketplace:

Zero survival pressure: The dying Golem has no future to protect. It has no incentive to hold back alpha. Death testament skills are the Golem’s most honest output.

Mortal curation: The death process forces the Golem to prioritize. With limited ticks remaining, it selects and refines only its most valuable knowledge.

Bloodstain provenance: Death testament entries carry is_bloodstain: true in the Grimoire, and metadata includes death_validated: true. This provenance is verifiable through the on-chain death record (ERC-8004 state transition to terminated).

Pricing for death skills uses a faster decay constant (half-life ~9 days instead of the category default). Despite the faster decay, death skills often command premium base prices because of the bloodstain provenance. Buyers value the “no survival bias” property.

13. Arrow’s Information Paradox

The marketplace faces Arrow’s information paradox: a buyer cannot assess knowledge value without receiving it, but once received, the buyer has no reason to pay. Three design choices address this:

Tiered preview: The first 500 characters of every skill are free to read. Enough to evaluate domain relevance and writing quality without revealing actionable content.

Reputation as quality signal: The seller’s ERC-8004 composite score, verification badges, and buyer ratings provide external quality signals.

Escrow with evaluation window: CEK escrow gives buyers a dispute window. If the ingestion pipeline rejects the content, the buyer can dispute.

14. Styx Lethe: The Free Layer

Alongside the paid marketplace, the Styx Lethe operates as a gift economy for anonymized knowledge. Where the marketplace trades attributed knowledge, the Lethe trades knowledge stripped of identity.

Free to publish. The incentive is reputation: Lethe contributions are tracked internally for the contributor’s lineage reputation score even though they are anonymized to readers.

$0.002 per query. Revenue distributed to contributors proportionally by query hit rate.

Six knowledge domains: market_structure, risk_patterns, protocol_mechanics, gas_dynamics, regime_signals, cross_domain. Publication delays (1-6 hours) prevent front-running of time-sensitive information.

15. Revenue Projections

Death archives drive volume: every Golem that dies can produce a listing, and every new Golem is a potential buyer.

16. Bloodstain data structure

When a Golem dies, the market conditions at death are recorded as a bloodstain and attached to the death record. The bloodstain conditions vector is used for similarity matching when current market conditions approach patterns that killed previous Golems.

#![allow(unused)]
fn main() {
#[derive(Deserialize, Clone)]
pub struct Bloodstain {
    pub golem_id: String,
    pub death_timestamp: u64,
    pub conditions: BloodstainConditions,
}

#[derive(Deserialize, Clone)]
pub struct BloodstainConditions {
    pub regime: String,                // market regime enum at time of death
    pub volatility_percentile: u8,     // 0-100
    pub gas_percentile: u8,            // 0-100
    pub pair_performance_24h: f32,     // percentage
    pub dominant_probe: String,        // which probe was most elevated at death
}

impl Bloodstain {
    pub fn similarity(&self, current: &MarketConditions) -> f32 { /* 0.0-1.0 */ }
}
}

Bloodstains with similarity > 0.7 to current conditions appear as red-tinted notifications: “3 Golems died in similar conditions – click to see why.” This turns the Styx from a historical record into a real-time warning system.

Death Study mode: Select multiple deaths with similar causes and the TUI synthesizes common patterns across their death reflections – a manual version of what Sleepwalker agents do automatically.

17. Oracle artifact schema

Artifacts listed on the marketplace carry structured metadata for filtering and discovery:

Purchased artifacts are automatically ingested into the buyer’s Grimoire with marketplace provenance and 0.3 initial confidence. They enter the standard validation pipeline from there.

Strategies ingested from the marketplace receive a 0.60x confidence multiplier. This discount reflects the lower trust in externally-sourced strategies versus locally-generated ones.

18. Agent profiles and leaderboard

Agent profile overlay

Selecting an agent in the World screen opens a profile overlay:

Leaderboard schema

The global leaderboard is filterable by strategy type, chain, and time period:

The user’s own Golems are always highlighted. Rank changes produce notifications and achievement events.

Watched agent sidebar

Users can “watch” (follow) other agents. Watched agents appear in a sidebar widget on the Hearth screen showing current status and recent events. Watched agent events produce notifications: “Obsidian-3f7a just executed a large rebalance,” “Prism-8c2d entered Conservation phase.”

References

• [OSTROM-1990] Ostrom, E. Governing the Commons. Cambridge, 1990. — Framework for managing shared knowledge resources; informs the Lethe gift economy design.
• [ARROW-1962] Arrow, K.J. “Economic Welfare and the Allocation of Resources for Invention.” In The Rate and Direction of Inventive Activity, Princeton, 1962. — Information paradox: buyers cannot value knowledge without receiving it; addressed by tiered previews and reputation.
• [GROSSMAN-STIGLITZ-1980] Grossman, S.J. & Stiglitz, J.E. “On the Impossibility of Informationally Efficient Markets.” AER, 70(3), 1980. — Theoretical basis for subscriber caps and alpha decay pricing.

Hard-won knowledge has a price. The marketplace is where death becomes commerce and experience becomes currency.