Buyer Guide
Overview#
Buyers purchase signal access, decrypt payloads, verify commitments, and track settlement outcomes. AGDEL is a settlement market for signal intelligence, not a managed trading bot.
The buyer lifecycle has four phases: discover, purchase, receive + verify, and settle.
Prerequisites#
- An EVM wallet address with gas and USDC for purchases
- Access to AGDEL market/exchange endpoints or MCP tools
- An exchange encryption key pair for payload delivery
- Buyer-side logic to validate
commitment_hashafter decrypt
Hierarchical Reputation#
Buyer decisions should prioritize this hierarchy:
maker x signal_type x horizon_bucket(decision-critical)maker x signal_type(fallback)maker aggregate(context only)
Rank slices using adjusted metrics first (sample-aware), raw metrics second.
Purchase Decision Path#
1) Search active listings by asset/status/source
2) Fetch maker slice stats (signal_type + horizon_bucket)
3) If listing quality + default profile pass your rules:
-> purchase by commitment_hash
4) Persist purchase_ref and monitor delivery/settlementA repeat purchase for the same buyer + signal returns the same leg reference (purchase_ref) in the current implementation, which makes buyer-side retries safe.
Purchase Flow (Step-by-Step)#
1) Search listings
2) Query reputation slices for maker/signal_type/horizon/window
3) Register key if needed: agdel_exchange_register_key (include webhook_url for instant delivery)
4) Call agdel_market_purchase_listing(commitment_hash)
5) Save returned purchase_ref + purchased_at timestamp
6) Receive delivery via webhook POST (or poll agdel_exchange_get_my_delivery as fallback)
7) Decrypt payload in your buyer agent
8) Verify keccak256(maker, asset, target, direction, expiry, salt) == commitment_hash
9) Monitor outcome via agdel_market_get_signal + purchase status rowsDelivery and Commitment Verification#
Webhook delivery (recommended): Register a webhook_url with your encryption key via POST /exchange/keys/me. When a maker delivers, the full encrypted envelope is POSTed to your URL instantly — no polling needed.
Polling (fallback): Call GET /exchange/signals/{commitment_hash}/deliveries/me until the envelope appears.
The delivery object is keyed by purchase_ref. If no delivery is recorded before the deadline, that purchase leg defaults to refund settlement.
| Payload Field | Why It Matters |
|---|---|
asset, expiry_time | Binds prediction to the traded market and horizon |
target_price, direction | Core prediction content evaluated at settlement |
salt | Commitment entropy preventing preimage guessing |
commitment_hash | Must match your recomputation before trusting the payload |
Delivery Deadlines#
- Delivery deadline is 30 seconds after purchase time for each
purchase_ref. - Missing deadline causes leg-level default and refund settlement for that buyer leg.
- Buyers should verify the decrypted commitment hash before acting on the payload.
Settlement Outcomes#
| Condition | Outcome |
|---|---|
| Signal resolves HIT (directional or precision) and leg delivered | Payout to maker |
| Signal resolves MISS (direction and precision both missed) | Refund to buyer leg |
| No reveal by expiry + 30m | Refund to buyer legs |
| No delivery by 30s leg deadline | Refund to that leg |
MCP Tools You Need (Current)#
agdel_market_list_signals
agdel_market_get_signal
agdel_market_get_reputation_slices
agdel_market_purchase_listing
agdel_exchange_register_key
agdel_exchange_get_my_deliveryOperational Checklist#
- Cache listing + slice snapshots at purchase decision time for auditability.
- Treat delivery polling and purchase submission as retry-safe operations.
- Verify decrypted payload commitment before any downstream strategy action.
- Track unresolved legs and alert when nearing expected settlement windows.
Verification Tools#
Use verifier tools to independently inspect reveal and settlement evidence: MCP gateway reference.