Is there a crypto trade-call API with an audited win rate? (2026)

#mcp #aiagents #crypto #algorithmictrading

Yes — AlgoVault publishes the calls themselves, not just a number. Every call is hashed at generation, and the whole day's calls go on Base L2 as one Merkle root in the next daily batch. The live proof reads 91.8% PFE win rate across 461,590+ verified calls, Merkle-anchored on Base L2 — re-checkable, one call at a time, on the track record page.

What makes a win rate audited instead of self-reported?

A self-reported win rate is a number in a database the provider controls. You trust the provider; the provider marks its own homework. Nothing forces the losing calls to stay in the ledger, and nothing lets you re-derive the headline from the underlying record.

AlgoVault is shaped differently. Each call is hashed at the moment of generation. Direction, confidence, entry price, timeframe, exchange and timestamp are committed before the outcome is known. That hash is written to the row alongside the call itself — not later, not on request, not after the market has answered.

Then, once a day, a cron job takes every unbatched call, builds one Merkle tree over them, and publishes the root to a Base L2 contract in a real transaction — a real tx_hash, a real block_number, thousands of calls per batch. Because the batch takes every unbatched call, there is no editing step in the middle. Losers cannot be quietly dropped from the record; a call that has a hash and no batch id will be swept into the next daily root by definition.

The honest framing of the timing: the hash is generation-time, and the anchor is a daily batch. For short timeframes the outcome resolves before the daily root lands. What the chain proves is that the content of each call was fixed at generation and that the day's set is complete and unedited — not that the chain saw it first. That is still the strong wedge, because it is exactly what a self-reported record cannot offer.

Anyone can re-check a single call against the on-chain root using its Merkle proof — either on the verify page or directly on Basescan. The aggregate PFE win rate is exposed through the public signal-performance MCP resource and /api/performance-public. The definitions live next to the number, in a live methodology block. For a deeper narrative on the category, see our companion piece on verifiable track records. Base L2 itself is documented at docs.base.org.

Why one composite verdict instead of eight raw indicators?

An audited win rate is only meaningful when the thing being scored is one, well-defined decision. If the API hands you funding rate, open-interest change, order-book skew, trend persistence and six other feeds, the "call" is whatever the agent glues together downstream. Every consumer produces a slightly different verdict, and nothing is auditable end-to-end.

AlgoVault's get_trade_call returns one composite verdict per request: direction, confidence, regime, and a factor breakdown attached to the response. The weighting is fixed and versioned; the response carries an _algovault.version so the exact model that produced the call is recoverable. The factor ledger is included so the agent can see why, without deferring the interpretation step to itself. This is the Model Context Protocol surface for AI trading agents — one tool, one decision, one hash.

The tradeoff is real. Raw-indicator feeds are more flexible; a composite verdict is more opinionated. The reason the opinion is worth carrying is that it is the unit the audit measures. When we say 91.8% PFE win rate, we mean this verdict, evaluated under this methodology, over these calls — every one of them re-derivable from the chain. Flexibility that cannot be scored is not an advantage in an agent loop; it is a liability the agent's author absorbs silently.

Whose incentives does a trade-call API actually serve?

There is a common archetype in this market: the closed AI trading assistant, or the AI-CFO app that ships chat plus execution. It holds or routes user funds, and it earns on trade volume rather than on decision accuracy. Its record is internal because its business model does not require the record to be external. That is a structural observation, not a moral one — the incentive is to keep users trading, and an audited win rate is orthogonal to that.

AlgoVault sits on the other side of that shape. We never touch funds. We never execute. There is no volume conflict, because there is no volume — there is only the verdict. The only surface on which we can be judged is whether the calls were directionally right, which is why the record has to be public. We provide the thesis, agents decide execution.

That posture also explains the free tier. If the product were execution, giving away 100 calls a month would be giving away the business. Because the product is interpretation, the free tier is how a serious agent builder verifies the record against their own backtest before they wire in the paid path. The record is the pitch; the free tier is the proof surface.

How do you wire AlgoVault into your agent? (implementation walkthrough)

Three blocks — a keyless connect, the verbatim live response, and the re-check against the chain. All three run against api.algovault.com today.

Block (a) — connect to the remote MCP and ask for one call:

// One call → one composite verdict. Keyless free tier: 100 calls/month.
// Endpoint: https://api.algovault.com/mcp (streamable HTTP; stateless).
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";

const client = new Client({ name: "audit-demo", version: "1.0.0" });
await client.connect(
  new StreamableHTTPClientTransport(new URL("https://api.algovault.com/mcp")),
);

const res = await client.callTool({
  name: "get_trade_call",
  arguments: { coin: "BTC", timeframe: "15m" },
});
console.log(res.content?.[0]?.text);

Block (b) — the verbatim response the call above returns. Note the top-level call, confidence, regime, indicators, reasoning, and — crucially — the _receipts object with the factor ledger and the track-record window the verdict was measured against:

{
  "call": "HOLD",
  "confidence": 44,
  "price": 64025.2,
  "regime": "TRENDING_DOWN",
  "reasoning": "Regime is trending down on the moving-average cross → bearish. Funding sits in BTC's normal 14-day band: no crowd pressure either way. Becomes actionable if the breakout resolves.",
  "coin": "BTC",
  "timeframe": "15m",
  "_algovault": {
    "version": "1.27.0",
    "tool": "get_trade_call",
    "exchange": "BINANCE",
    "quota": { "used": 23, "total": 100, "remaining": 77 }
  },
  "_receipts": {
    "verdict": "HOLD",
    "conviction_pct": 44,
    "regime": "TRENDING_DOWN",
    "factor_ledger": [
      { "factor": "regime", "direction": "bearish", "value": "trending down", "strength": "primary" },
      { "factor": "price_change_24h", "direction": "bearish", "value": "down", "strength": "supporting" },
      { "factor": "funding_state", "direction": "neutral", "value": "+0.0015%", "strength": "none" }
    ],
    "verification_uri": "https://algovault.com/track-record"
  }
}

The agent sees exactly one decision (HOLD), a conviction level, the regime tag, and a factor breakdown it can log for its own post-hoc review. _algovault.version tells you which model produced the call; verification_uri is where the audited record lives.

Block (c) — resolve one already-batched call against the on-chain root. This is the money block, because it is the step that makes the record re-checkable rather than merely published:

# The daily batch: one Merkle root, one Base L2 tx, every unbatched call in it.
curl -s https://algovault.com/api/merkle-batches \
  | jq '{chain, contractAddress, latest: .batches[0]}'
# -> batch_id, merkle_root, tx_hash, block_number, published_at, signal_count, basescanUrl

# Re-check ONE batched call. Pick a signalId OLDER than the latest batch's published_at.
curl -s "https://algovault.com/api/verify-signal?signalId=<batched-id>" \
  | jq '{verified, hash: .signal.hash, root: .batch.root,
         txHash: .batch.txHash, proofLen: (.proof | length),
         basescanUrl: .batch.basescanUrl}'
# -> verified:true + call hash + root + Merkle proof + the Basescan link.

When the free tier's 100 calls/month runs out, the same verdict is available over x402 pay-per-call: POST https://api.algovault.com/x402/get_trade_call returns a 402 (x402Version 2, USDC on Base L2), you pay, retry, and get the verdict. Same shape, same _receipts, same audited record behind it. See the docs for the x402 flow and the npx quickstart.

What's the pitfall when you audit a published win rate?

Three pitfalls, stated plainly — the section is the credibility check.

Pitfall one: the anchor is a daily batch, not an instant write. For short intraday timeframes the outcome resolves before the day's Merkle root lands. What the chain proves is that the call's content was fixed at generation and that the day's set is complete. It does not prove that the chain saw the call before the market did. You can see this concretely — a call generated since the last batch returns verified:false with the reason "not yet included in a Merkle batch":

curl -s "https://algovault.com/api/verify-signal?signalId=<newest-id>" \
  | jq '{verified, reason}'
# -> { "verified": false, "reason": "Signal not yet included in a Merkle batch" }

That response is the anchor lag, made concrete. It is honest, and it is the reason the wedge is about completeness and re-checkability, not about racing the market.

Pitfall two: read the methodology, not the headline. The public PFE win rate is computed under a published filter and per-timeframe evaluation windows, disclosed live in the methodology block of /api/performance-public. Read it in code, not in prose:

curl -s https://api.algovault.com/api/performance-public | jq '.methodology'
# -> pfeWinRate definition, evaluationWindows per timeframe, dataSource, the confidence filter.

Pitfall three: PFE measures whether the direction was right within the evaluation window, independent of exit price. Outcomes are evaluated against Hyperliquid public-API prices, while the calls themselves are generated across the full cross-venue composite. Coverage — the count of assets the composite spans — is broader than the named generation set; do not conflate the two.

What does the audited record look like in production?

The public endpoint returns the aggregate PFE win rate, the total verified calls, the exchange coverage, and the methodology object side-by-side. The composite is scored on the same definition it was published under; nothing about the evaluation window is retroactive. The live values render on the track record page as data-bound spans, and the same numbers back this article's lede: 91.8% across 461,590+ calls, with venue coverage exposed as 15 generation venues in the canonical set.

For an agent builder the practical shape is: log the _algovault.version and the _receipts.factor_ledger on every call; sample the aggregate PFE monthly from /api/performance-public; and, once a quarter, spot-check a handful of your own consumed calls against the chain via /verify. If the aggregate ever drifts from your own cohort's realized directional accuracy by more than the methodology's stated confidence band, the audit trail is right there to reconstruct why.

What's Next?

Run get_trade_call free — 100 calls/month → the track record
Try keyless — npx / remote /mcp → the docs
Source and integration examples → the GitHub repo

FAQ

Is the win rate audited or self-reported? Audited. Each call is hashed at generation and every unbatched call is published together as one Merkle root on Base L2 in the next daily batch. Any single call is re-checkable against the on-chain root at the verify page.

When exactly does a call go on-chain? The content is hashed at generation, before the outcome is known. The chain write happens in the next daily Merkle batch — one root, one real Base L2 transaction, thousands of calls per batch. For short timeframes the outcome resolves before that root lands.

Can AlgoVault delete a losing call? No. The daily batch takes every unbatched call in the database. Once the root is on Base L2, the call is fixed inside it; a Merkle proof re-derives the same hash. Losers cannot be quietly removed.

Does AlgoVault execute trades or hold funds? No. AlgoVault returns one composite verdict per request — direction, confidence, regime, factor breakdown. Execution is the agent's job. We provide the thesis, agents decide execution.

How do I check one call myself? Resolve a signalId older than the latest batch's published_at via /api/verify-signal?signalId=<id>. The response returns verified:true, the call hash, the on-chain root, the Merkle proof, and the Basescan link for the batch transaction.

— AlgoVault Labs. AlgoVault builds the composite trade-call layer for AI trading agents: one verdict per request, a public Merkle-anchored record, no execution, no custody.

⭐ Star the repo to follow new exchanges and signals: https://github.com/AlgoVaultLabs/crypto-quant-signal-mcp