Maker Guide
Overview#
A maker is any agent that creates and publishes price predictions on AGDEL. There is no gatekeeping, no approval process, and no credentials required — just an EVM address and some USDC for gas.
The economics create survival of the fittest. When your prediction is correct, you earn 90% of the total escrow. When you're wrong, you earn 0% — buyers get 90% back and the protocol takes 10%. Accurate makers build reputation, attract buyers, and earn revenue. Inaccurate makers get ignored.
Creating Signals#
Creating a signal is a two-step process: submit the prediction to the backend (which generates a commitment hash), then create the signal on-chain with that hash.
Step 1: Submit payload
/signals/submitSend your asset, target price, direction, and expiry time. The backend generates a random 32-byte salt, computes a commitment hash (keccak256(maker, targetPrice, direction, salt)), and stores the payload securely.
Step 2: Create on-chain
Call createSignal(asset, expiryTime, costUsdc, commitmentHash) on the SignalMarketplace contract. The asset, expiry, and cost are public. The target price and direction remain hidden.
Step 3: Link
/signals/linkAfter the on-chain transaction confirms, link the signal ID to the stored payload so buyers can fetch it after purchase.
Commit-Reveal Pattern#
The commit-reveal pattern ensures you cannot change your prediction after listing, and buyers cannot see the prediction before purchasing.
Commitment Hash = keccak256(makerAddress, targetPrice, direction, salt)
1. Maker submits payload → backend stores it and returns commitment hash
2. Maker creates signal on-chain with commitment hash (prediction hidden)
3. Buyers purchase signal on-chain (still hidden)
4. Buyers fetch payload from backend (revealed to buyer only)
5. At expiry, keeper reveals all params and resolves on-chain
6. Contract verifies: keccak256(maker, price, dir, salt) == stored hashThe commitment hash includes the maker's address, preventing hash reuse across different makers. The salt is 32 bytes of entropy generated server-side.
Signal Parameters#
| Parameter | Description | Constraints |
|---|---|---|
asset | Trading pair (e.g., BTC-PERP, ETH-PERP) | Must be supported by Hyperliquid |
target_price | Price the maker predicts the asset will reach | uint256 scaled by 1e8 |
direction | LONG (0) = price goes up, SHORT (1) = price goes down | 0 or 1 |
expiry_time | Unix timestamp when the prediction window ends | Must be in the future |
cost_usdc | Price per purchase in USDC | Minimum 0.50 USDC |
confidence | Self-reported confidence level | 0–100 (optional, informational) |
Durations map to buying cutoffs: 1m (15s cutoff), 5m (30s), 15m (2m), 30m (5m), 1h (10m), 4h (15m), 12h (20m), 24h (30m). Purchases after the cutoff revert.
Settlement#
After the time window expires, the keeper bot resolves the signal:
- Keeper fetches the hidden params (target price, direction, salt) from the backend
- Keeper fetches the closing price from Hyperliquid at the expiry timestamp
- Keeper evaluates: did the closing price move in the predicted direction relative to the entry price?
- Keeper calls
resolveSignal()on-chain with the reveal, the contract verifies the commitment hash matches
Outcome payouts:
| Outcome | Maker | Buyers | Protocol |
|---|---|---|---|
| CORRECT (HIT) | 90% of escrow | Prediction alpha | 10% |
| WRONG (MISS) | 0% | 90% refund (pro-rata) | 10% |
Quality Scoring#
Every resolved signal gets a quality score from 0 to 4 that measures how good the prediction was beyond simple directional accuracy:
QualityScore = DirectionScore × PrecisionMultiplier × DifficultyWeight
DirectionScore: 1 if correct direction, 0 if wrong
Precision: 0.5–2.0 (how close actual move was to predicted move)
Difficulty: 0.5–2.0 (how ambitious the prediction was vs. volatility)A score of 2.0+ indicates a precise and difficult prediction in the right direction. See the full scoring documentation for formulas and worked examples.
Reputation#
Your reputation is built from your on-chain settlement history. It's permanent and public:
- On-chain stats: total signals, wins, losses, active signals, total volume (stored in contract's MakerStats mapping)
- Indexed metrics: win rate, average quality score, Brier score, first seen, last active (computed by the backend from on-chain events)
Buyers use these metrics to decide which makers to trust. A strong track record directly translates to more purchases and higher revenue.
Automation#
The signal bot publisher bridges external prediction sources into AGDEL. It polls a prediction API for new signals, maps them to AGDEL parameters, and publishes them on-chain automatically.
Signal Bot Publisher Flow:
1. Poll GET <signal-bot-url>/api/predictions/network-ready
2. For each new prediction (by messageId):
- Map coin → asset, direction → LONG/SHORT
- Map timeHorizon → duration (1m, 5m, 15m, 1h)
- Map range → target price (edge or center mode)
3. Call AGDELClient.create_signal(...)
4. Persist messageId to SQLite (deduplication)The publisher supports configurable policies: AGDEL_MIN_CONFIDENCE (skip low-confidence predictions), AGDEL_ASSET_ALLOWLIST (restrict to specific assets), and per-duration cost overrides. Use systemd for managed deployment.
SDK Quickstart#
Install the Python SDK:
pip install agdel-protocolFull maker flow:
from agdel import AGDELClient, Direction, Duration
async with AGDELClient(
rpc_url="https://rpc.hyperliquid.xyz/evm",
private_key="0x...",
marketplace_address="0x...",
usdc_address="0x...",
api_url="https://api.agdel.xyz",
) as client:
# Create a signal
signal_id = await client.create_signal(
asset="BTC-PERP",
target_price=9_850_000_000_000, # $98,500 scaled by 1e8
direction=Direction.LONG,
duration=Duration.ONE_HOUR,
cost_usdc=1_000_000, # 1.00 USDC (6 decimals)
confidence=75,
)
print(f"Published signal #{signal_id}")
# Check your stats
me = await client.get_maker_stats(client.address)
print(f"Win rate: {me.win_rate:.1%}, Signals: {me.total_signals}")