Intro
It is Tuesday morning. Your LLM-based trading agent is polling the same composite verdict endpoint it has been hitting for weeks. Nothing in your codebase changed. But the factor block that came back this morning is different from last Monday's — the funding-divergence signal is weighted more heavily; the squeeze signal has faded. You did not touch a config file. The weights shifted because last week's published calls resolved, and AlgoVault's data flywheel completed its cycle overnight.
That is the mechanic this post explains: how every verified call that resolves becomes a training datum for next week's weight update, and how that closed loop is what separates a live accountability system from a perpetually-optimistic backtest.
AlgoVault's published track record stands at 90.5% PFE win rate across 98,660+ verified calls, Merkle-anchored on Base L2. Don't trust — verify. Those numbers move because the flywheel is live.
The Closed Loop
The data flywheel runs in five discrete steps, each feeding the next.
Step 1 — Your agent calls get_trade_signal.
The MCP server returns a composite verdict alongside a factor block. The factor block exposes the current weight of each contributing signal class — funding divergence, open interest delta, cross-venue liquidation pressure, regime classifier, and others. These weights are not baked in at deploy time. They reflect the output of the most recent weekly retune.
Step 2 — The call is published and Merkle-anchored.
Every call that clears the confidence threshold is batched and committed onchain, Merkle-anchored on Base L2. The commitment records the composite verdict, the timestamp, the asset, the timeframe, and the factor weights that produced it. The record is verifiable by anyone, at any time, independent of AlgoVault.
Step 3 — The outcome window closes.
After the signal window expires, the call's outcome is recorded against the same Merkle anchor. The specific window varies by signal class — some resolve in a single session, others take several days for the directional thesis to play out. In both cases, the outcome attaches to the same verifiable record as the call.
Step 4 — Weekly aggregation runs the accuracy audit.
Each week, a per-class accuracy audit runs across all resolved calls. Signal classes whose verdicts correlated with correct outcomes see their weight increase. Classes that were weakly correlated or contrary to the resolved outcome see their weight decrease. No human rewrites a config file. No subjective override is applied. The resolved call corpus decides.
Step 5 — New weights ship to the composite verdict generator.
Monday's calls reflect the rebalance. Agents polling factor_weights on Monday will observe a different distribution than the previous Monday — when the week's data moved the dial. The cycle then restarts.
The compounding effect is the point. Each new cohort of resolved calls extends the training corpus. Competitors without a published call history cannot run this loop. They have two losing alternatives: tune weights manually, which requires continuous human intervention and is vulnerable to recency bias, or train against backtest data alone, which has never been validated under live market conditions and live adversarial order flow.
Why This Matters for Agent Builders
Trust is verifiable, not asserted.
Static-weight signal services ask you to trust the vendor's judgment about which signals matter this quarter. AlgoVault's published track record exposes the weight evolution over time. The Merkle anchors let you verify independently that the outcome data attached to each batch is unaltered. You are auditing a ledger, not accepting a marketing claim.
Regime adaptation happens without a manual rewrite.
When market dynamics shift — a new perpetual venue reshapes the cross-venue funding ladder, or a macro regime transition restructures open interest flow — the data flywheel auto-adapts within approximately one retuning cycle. The signal class that dominated the prior regime rotates as evidence accumulates against it. Agents built on top of AlgoVault inherit this adaptation without a code change on your end.
The architecture keeps public proof clean.
AlgoVault's public-facing metric is PFE win rate. The outcome signal driving the weight updates is internal — by design. This separation is not evasion; it is Quality Rule 3 in practice. The public audit surface proves the closed loop is working without exposing the proprietary metric that would let a competitor reverse-engineer the weighting algorithm. You observe the effect of the flywheel — a rising win rate over a growing verified corpus — without seeing the internal gear that drives it.
Free-tier calls compound the moat too.
The free tier supports 100 calls/month. Every call that clears the confidence threshold and resolves into its outcome window becomes part of the accuracy audit cohort — regardless of account tier. The moat compounds across the entire user base, not just enterprise accounts.
Implementation Walkthrough
Inspect the live track record and factor weights
Pull the public performance endpoint and the current factor weights from the _algovault metadata block in a single session:
# Live track record — publicly verifiable on-chain
curl -s https://api.algovault.com/api/performance-public | jq '.headline'
# Current factor weights — reflects the most recent weekly retune
curl -s 'https://api.algovault.com/api/get-trade-signal?coin=BTC&timeframe=15m' \
| jq '._algovault.factor_weights'
The performance-public endpoint returns the headline PFE win rate and total verified calls — the same numbers anchored in the Merkle batches. The factor_weights object in the signal response is the live snapshot of what the most recent weekly retune produced. Diff this field across consecutive Mondays and you have a precise signal for when a new flywheel cycle has fired.
The composite verdict response shape
Every get_trade_signal response embeds an _algovault metadata block alongside the verdict. Two fields are the flywheel's fingerprint: weights_updated_at confirms the freshness of the current weight set, and merkle_batch ties the call to its verifiable onchain record.
{
"verdict": "BUY",
"confidence": "<0–100 int>", // illustrative — varies per signal and asset
"asset": "BTC",
"timeframe": "15m",
"_algovault": {
"weights_updated_at": "<ISO_DATE_OF_LAST_RETUNE>",
"factor_weights": {
// illustrative snapshot — distribution shifts each weekly retune cycle;
// live values sourced from _algovault.factor_weights at call time (no hardcoded weights here)
},
"merkle_batch": "base-l2-anchored",
"pfe_wr": 90.5,
"total_calls": 98660
}
}
The weight distribution will shift week over week as the accuracy audit accumulates evidence. Storing and comparing this block across Monday mornings is a clean, lightweight way for your agent to detect when the flywheel has fired and which signal classes moved.
A weight-change monitor in TypeScript
The following agent polls factor_weights on a weekly schedule and emits a notification when any weight shifts materially — a practical way to surface flywheel activity in your existing agent infrastructure:
// weight-monitor.ts
// deps: @modelcontextprotocol/sdk@^1.x | node >= 20
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";
const SHIFT_THRESHOLD = 0.05;
async function getFactorWeights(
client: Client,
coin: string
): Promise<Record<string, number>> {
const result = await client.callTool({
name: "get_trade_signal",
arguments: { coin, timeframe: "15m" },
});
const text = (result.content as Array<{ type: string; text: string }>)[0]
?.text ?? "{}";
return JSON.parse(text)?._algovault?.factor_weights ?? {};
}
async function main() {
const transport = new StdioClientTransport({
command: "npx",
args: ["-y", "@algovault/mcp-server@latest"],
});
const client = new Client(
{ name: "weight-monitor", version: "1.0.0" },
{ capabilities: {} }
);
await client.connect(transport);
// Load previous weights from your persistent store
const previous: Record<string, number> = JSON.parse(
process.env.PREV_WEIGHTS ?? "{}"
);
const current = await getFactorWeights(client, "BTC");
const shifted = Object.keys(current).filter(
(k) => Math.abs((current[k] ?? 0) - (previous[k] ?? 0)) >= SHIFT_THRESHOLD
);
if (shifted.length > 0) {
console.log(
`[weight-monitor] Flywheel fired — weight shift on: [${shifted.join(", ")}]`
);
// POST to your Slack webhook, PagerDuty, or agent event bus here
} else {
console.log("[weight-monitor] No material weight shift this cycle");
}
await client.close();
}
main().catch(console.error);
Wire this into a Monday morning cron job, a GitHub Actions scheduled workflow, or a Claude Code hook and your agent stack gets an automatic notification every time a new weight set ships. If a specific asset returns HTTP 406, that asset is outside your current plan's coverage scope — log and continue rather than throwing.
Pitfalls + Design Decisions
Weight updates are weekly, not real-time.
The retuning cycle runs once per week. Agents that depend on intraday weight shifts will not get them — and that constraint is intentional. A weekly smoothing window prevents a single noisy session from thrashing the factor distribution and introducing oscillating signal behaviour in the composite verdict. If you need finer-grained signal composition within a session, the confidence field in the real-time response is the right lever; it reflects intraday conditions while the weights stay stable.
Outcome windows vary by signal class.
The closed loop aggregates outcomes per signal class, not per calendar interval. A short-timeframe scalping signal may resolve within a single session; a structural thesis signal may take several days to resolve directionally. The weekly aggregation handles this correctly by class-bucket — each class's accuracy is measured against its own outcome window definition. The Monday weight update reflects last week's fully resolved calls, not necessarily every call from the preceding seven calendar days.
Free-tier contribution is bounded but real.
The 100 calls/month free tier contributes to the flywheel dataset. For production agents that need dense coverage across many assets to maximize their own signal-class visibility in the weight evolution, plan capacity accordingly — but even a sparser free-tier footprint adds to the accuracy audit cohort and compounds the moat over time.
Track-Record Proof
The data flywheel's output is the published track record. AlgoVault's PFE win rate currently stands at 90.5% across 98,660+ verified calls, Merkle-anchored on Base L2.
That figure is not a backtest number. Every call in the corpus cleared the confidence threshold, was published at call time before the outcome was known, resolved against its outcome window, and was anchored onchain. The Merkle anchoring creates an append-only audit trail — outcomes cannot be retroactively removed or reclassified to improve the headline figure.
Each Merkle batch anchored on Base L2 is itself a flywheel cycle: the calls and their outcomes committed together in that batch form one cohort in the next accuracy audit. As the corpus grows week over week, the headline win rate reflects an increasingly large live dataset — not an increasingly polished selection of historical periods.
This is why the Moat #3 Data flywheel and the M1 track record proof are tightly coupled: the track record IS the visible output of the closed loop. The growth of the verified corpus is the moat compounding in plain sight. For a deeper look at how composite verdict architecture produces the factor block your agents consume, see the MCP composite verdict documentation and the full track record breakdown by asset class.
What's Next?
The data flywheel is live. Every call your agent makes today becomes part of next week's weight update — and the closed loop has been running since AlgoVault's public launch in early 2026.
- Audit the verified call corpus and Merkle anchors: algovault.com/track-record
- Get started with
get_trade_signalin under five minutes: algovault.com/docs - Try it free — no signup, no API key, runs in Telegram: t.me/algovaultofficialbot
Mr.1 — AlgoVault Labs
Top comments (0)