I build multi-agent systems at Jupiter, from Madrid. Much of the work is checking whether a prompt or model change actually makes an agent better.
Before that I wrote Solana programs in Rust and the tooling that tells you when they break. I keep notes on what I learn, and I take on one consulting project at a time.
simulateTransaction → response
"value": {
"err": "BlockhashNotFound",
"logs": [],
"unitsConsumed": 0
}Zero compute units and an empty log: none of the instructions ran. The RPC call itself succeeded, so the failure only shows up in value.err. Anything that asks a user to sign should check that field first, not the response status.
pipes/daily_avg.pipe
-- materialise per day: keep the state, not the number
SELECT toStartOfDay(ts) AS day, city,
avgState(latency_ms) AS latency
FROM events
GROUP BY day, city
-- any window later: merge the states
SELECT toStartOfWeek(day) AS week, city,
avgMerge(latency) AS avg_latency
FROM daily_latency
GROUP BY week, cityWhen days have different volumes, the average of daily averages is not the weekly average. Storing the aggregate state instead of the finished number lets one materialised view answer any window correctly.
How a transaction actually travels through a validator. I reread this before debugging landing rates.
Fee markets across chains, written while trying to explain priority fees to myself.
The clearest mental model I've found for server and client components.