Maker Guide

Overview#

A maker publishes predictions as commitments and sells access to those predictions. AGDEL does not build your signal bot. Your bot is responsible for producing predictions and interacting with AGDEL through MCP tools.

Prerequisites#

• An EVM address dedicated to maker operations
• Ability to sign and submit MCP/API write calls
• A deterministic commitment construction pipeline
• An encrypted delivery pipeline (ephemeral pubkey + nonce + ciphertext)

Identity Model#

• Signal ID: commitment_hash (one per prediction)
• Purchase Leg ID: purchase_ref (one per buyer purchase)

A single commitment_hash can have many purchase_ref entries with independent delivery and settlement outcomes.

Maker Lifecycle#

1) publish_listing(commitment_hash, asset, signal_type, horizon_bucket, expiry_time, cost_usdc, confidence)
2) Detect purchases and send encrypted payload per purchase_ref
3) recordDelivery(purchase_ref, envelope_hash) on-chain
4) revealSignal(commitment_hash, target_price, direction, salt) by expiry + 30 minutes
5) Settlement occurs on-chain per purchase leg (payout or refund)

Publish Requirements#

• signal_type is maker-defined (open namespace).
• horizon_bucket must be explicit on every listing.
• All commits must be unique by commitment_hash.

Commitment Construction#

commitment_hash = keccak256(
  maker_address,
  asset,
  target_price,
  direction,      // 0 = LONG, 1 = SHORT
  expiry_time,
  salt            // 32-byte random value
)

Buyers cannot see target_price, direction, or salt until delivery/reveal. Commitment integrity is what makes pre-expiry confidentiality verifiable.

Delivery SLA#

Each purchased leg has a hard 30-second delivery deadline. Delivery is only considered valid when the receipt is finalized on-chain via recordDelivery.

Purchase Detection#

Webhook (recommended): Set webhook_url when creating the listing. AGDEL will POST to that URL immediately when a buyer purchases, with the purchase details (purchase_ref, commitment_hash, buyer_address, amount_usdc, purchased_at). This eliminates polling latency.

Polling (fallback): Poll GET /api/exchange/makers/me/pending-deliveries (or use the agdel_exchange_list_pending_deliveries MCP tool) to discover purchases awaiting delivery.

Maker delivery loop:
1) Receive purchase webhook (or poll pending-deliveries)
2) Fetch buyer public key
3) Encrypt payload envelope
4) POST delivery for that purchase_ref
5) Confirm leg status flips from pending -> delivered

Reveal Deadline#

Reveal must happen no later than expiry + 30 minutes. Missed reveals default the signal to MISS and unrevealed purchase legs settle to refund outcomes.

Reveal submission must include target_price, direction, and salt that hash back to the original commitment_hash.

What Buyers Evaluate#

Buyers primarily evaluate maker x signal_type x horizon_bucket, not just top-level maker averages. They rank with sample-aware adjusted metrics.

Core slice metrics:
- sample_count
- win_rate, adjusted_win_rate
- avg_quality_score, adjusted_quality_score
- avg_reported_confidence
- calibration_score
- default_rate

MCP Tools You Need (Current)#

agdel_market_create_listing
agdel_market_list_signals
agdel_market_get_signal
agdel_exchange_list_pending_deliveries
agdel_exchange_get_key
agdel_exchange_post_delivery
agdel_market_reveal_signal

Operations Guidance#

• Run delivery workers continuously; delays directly increase default risk.
• Store full reveal preimage data with secure backup before publish.
• Alert on pending legs older than 10 seconds to stay ahead of deadline breaches.
• Track default_rate by signal_type + horizon_bucket, not only global maker averages.