A deployer with a 40% lifetime bond rate tells you almost nothing. That number includes their first five tokens (when they were figuring out what worked), a three-month cold streak in the middle, and their last twenty tokens where they hit 65%. You care about the last twenty. Everything else is noise.
/v1/deployer-hunter/{wallet}/trajectory is built around that asymmetry. Instead of a flat lifetime number, it returns the deployer's career as a sequence: rolling bond rates, streaks, trends, recovery speeds, and best/worst stretches. This post walks through what each field tells you, and how to use them to decide whether a deployer's next launch is worth a snipe or a skip.
The problem with lifetime stats
Every deployer-tracking tool shows you lifetime bond rate. Almost none show you the shape of the career. That matters because deployer skill is not static:
- Most deployers improve over time — their first ten tokens are rough, their next thirty get better.
- Hot hands exist. A deployer who just bonded three in a row is objectively a better bet on their next launch than the same deployer six months ago during a cold streak.
- Cold hands exist too. A deployer mid-way through six failed launches is probably not the alpha your sniper is treating them as.
Lifetime bond rate smooths all of that into a single number. Trajectory unpacks it.
The endpoint response
GET /v1/deployer-hunter/{wallet}/trajectory (PRO+ tier) returns a two-section object:
{
"deployer": {
"wallet_address": "5xy...",
"total_tokens_deployed": 73,
"total_bonded": 31,
"bonding_rate": 0.425,
"recent_bond_rate": 0.60,
"tier": "GOLD"
},
"trajectory": {
"current_streak": { "type": "bond", "count": 3 },
"longest_bond_streak": 5,
"longest_fail_streak": 8,
"rolling_bond_rates": [
{ "window_end": 10, "bond_rate": 0.2 },
{ "window_end": 20, "bond_rate": 0.3 },
{ "window_end": 30, "bond_rate": 0.4 },
...
{ "window_end": 73, "bond_rate": 0.7 }
],
"trend": "improving",
"avg_days_between_deploys": 2.3,
"avg_recovery_tokens": 2.1,
"best_stretch": { "start_index": 55, "end_index": 64, "bond_rate": 0.8 },
"worst_stretch": { "start_index": 12, "end_index": 21, "bond_rate": 0.0 },
"total_tokens_analyzed": 73
}
}
Eight fields, each answering a different question about the deployer.
What each trajectory field is actually telling you
current_streak — the most actionable single field. A deployer mid-way through { type: "bond", count: 3 } is a fundamentally different bet than the same deployer at { type: "fail", count: 5 }. Streaks are real: deployer momentum tends to persist for 3–10 tokens before regressing. Snipe into a bond streak, fade a fail streak.
longest_bond_streak vs longest_fail_streak — the career extremes. A deployer with longest_bond_streak: 7 has demonstrated the ability to hit sustained consensus. A deployer with longest_fail_streak: 15 has demonstrated the ability to grind through long cold patches — which cuts both ways. Either they eventually find their feet, or they're stubbornly deploying the same tired playbook.
rolling_bond_rates — the shape of the career. A monotonically rising series (0.2 → 0.3 → 0.5 → 0.7) is a deployer leveling up. A bell curve (0.2 → 0.7 → 0.4) is a deployer whose meta stopped working. A flat line at 0.3 is a journeyman. Plot it and the story jumps out.
trend — the endpoint's own verdict: improving (recent window is >5% above lifetime), declining (>5% below), or stable. Cheap way to filter a watchlist without computing the series yourself.
For the non-API, point-and-click version of this same trajectory read, our walkthrough on how to spot winning deployers before their tokens bond covers the manual workflow.
avg_days_between_deploys — cadence. Under 1 day is a factory (probably multiple token ideas per week, low per-token care). Over 7 days is a curator (fewer shots, more thought per shot). Both can work; the tell is whether the bond rate matches the cadence.
avg_recovery_tokens — when this deployer fails, how many tokens does it take them to bond again? A value of 1.5 means they bounce back fast. A value of 4.0 means every cold spell is genuinely long. Combined with current_streak: { type: "fail" }, this tells you roughly when to start paying attention again.
best_stretch / worst_stretch — the highest and lowest 10-token windows in the career. Useful for reality-checking recent_bond_rate: if their recent 10-token rate of 0.6 matches their best-ever stretch, you're looking at someone riding a temporary hot streak that will regress. If it matches their steady-state average, it's probably the new baseline.
Three patterns that matter
The Improving Factory. High deploy cadence (< 2 days), trend = improving, rolling rates climbing over the last 30 tokens. These deployers are in learning mode and getting better. Their next token has meaningfully better odds than their lifetime stats imply. Weight recent outcomes 2–3x.
The Consistent Grinder. Moderate cadence (2–5 days), trend = stable, rolling rates steady across 40+ tokens. These are the safest bets — not the biggest winners, but the lowest variance. Good backbone for any deployer watchlist.
The Hot Hand in Cold Water. Recent streak = bond, but trend = declining and worst_stretch is in the last 20 tokens. Be skeptical. A lucky 2-in-a-row after a bad stretch is regression noise, not signal. Wait for 4+ before re-weighting them up.
The Cold Fader. Current streak = fail, count ≥ 4, avg_recovery_tokens < 2. They tend to bounce back fast, so a 4–5 token fail streak is actually close to the moment you want to start watching again.
Wiring it into a sniper pipeline
The trajectory endpoint is not a realtime feed. It's what you run after /deployer-hunter/recent-bonds surfaces a new token, to decide whether to act on it.
import { MadeOnSol } from "madeonsol";
const client = new MadeOnSol({ apiKey: process.env.MADEONSOL_API_KEY! });
async function shouldSnipe(deployerWallet: string): Promise<{
action: "snipe" | "watch" | "skip";
reason: string;
}> {
const { deployer, trajectory } = await client.deployerHunter.trajectory(
deployerWallet
);
// Fresh deployer — no history to judge
if (deployer.total_tokens_deployed < 10) {
return { action: "watch", reason: "sample size too small" };
}
// Cold streak
if (trajectory.current_streak.type === "fail" && trajectory.current_streak.count >= 4) {
return { action: "skip", reason: `in a ${trajectory.current_streak.count}-token fail streak` };
}
// Hot streak + improving trend = green light
if (
trajectory.current_streak.type === "bond" &&
trajectory.current_streak.count >= 2 &&
trajectory.trend === "improving"
) {
return { action: "snipe", reason: "hot streak on improving trajectory" };
}
// Stable + good lifetime = default-in
if (trajectory.trend === "stable" && deployer.bonding_rate >= 0.35) {
return { action: "snipe", reason: "stable career, above-average bond rate" };
}
return { action: "watch", reason: `trend=${trajectory.trend}, streak=${trajectory.current_streak.type}/${trajectory.current_streak.count}` };
}
shouldSnipe("5xy...").then(console.log);
The decision surface is much better than a threshold on lifetime bond rate alone. Two deployers with identical 42% lifetime rates can have opposite trajectories — one with a cold streak and declining trend should be faded, the other with a hot streak and improving trend should be sized into. For the broader workflow of turning these signals into actual entries, see our guide on using the .
