Blog

Hands-on NTT benchmarks over BabyBear and Goldilocks fields, connecting Jim Posen’s ZK Hack talk on high-performance SNARK/STARK engineering to real Rust code.

Final milestone wrap-up: IcRamp v2 with a simplified vault, ICP-driven state instead of on-chain commit/uncommit, and ic-alloy-powered EVM reads for getDeposit.

We finish the pay-with-crypto flow: from Locked orders to on-chain payments, matching provider assets, and verifying EVM/Solana txs on the backend.

Practical Learnings from ZK Hack with JP Aumasson with hands-on benchmarks: SHA-256/512, BLAKE3, Poseidon. What does 'ZK-friendly' really mean?

Frontend wiring for the experimental 'pay with crypto' path: crypto providers in the user profile, filtered provider selection in Create Order, and a compact order card UX for onrampers choosing how to pay.

We add an experimental 'pay with crypto' path that lets onrampers settle in stables on a different chain than the escrowed asset. Includes provider model refactor and order validation. Frontend exposure starts with stables for speed.

We add partial fills: the onramper can lock only a fraction of the order, pay, and get a proportional crypto payout while the rest stays open. Single lock path, pro-rata fees, idempotent fill records, and listener-safe completion.

Added liquid (top‑up) orders and unified provider icons across the app. Safe processing lock on the backend, fee recomputation on the new total, and a polished top‑up UI with available-balance max.

End-to-end Stripe payments for orders: Onramper pays by email, Offramper receives via Connect destination charges. Per‑order success/cancel, email verification, and a resilient FE redirect flow.

Frontend wiring for Stripe Connect: a register flow that survives redirect/refresh, provider cards UI, and Create Order with destination charges. Includes the Onramper≠Offramper split and backend-validated providers.

Starting Milestone 2: bringing Stripe Connect (destination charges) into icRamp with IPv6-friendly HTTPS outcalls, multi-region key routing, and Candid-first tests.

I stress-tested a one-sided, USDC-anchored LP strategy overnight: ~15 rebalances, lots of fee accrual, a few bugs, and a clearer picture of what to fix next. We tightened pool orientation, made SOL/WSOL funding sane, added skew gates (TVL/fees), and wrote proper lineage + flows. The monitor is quieter—until it needs not to be.

I debugged the PnL, refactored the messy code we left implemented in our last devlog and made everything more compact and debuggable.

I moved position funding and settlements to a USDC base, fixed a sneaky PnL bug (price/mint orientation), taught the monitor to chill (cooldown + “in-range = HOLD”), and battle-tested open/close scripts with ledgered flows. It’s finally… boring—in the good way.

I rewired RPC handling with role-based profiles, unified LP strategy controls, fixed PnL accounting, and executed a live one-sided rebalance on a PUMP/USDC DLMM pool over gRPC—end to end with Supabase ledgering.

Before we let the monitor act on positions, we hardened the boring bits: one source of truth for decimals, fast prices, safe BigInt math, and clean balance reads. The goal is simple: trustworthy PnL so alerts and actions are correct.

I stripped our Telegram surface down to a fast, durable “Lite” mode: no Kafka, no AI agent in the middle—just clean wallet UX, on-chain balances via RPC, token prices from Jupiter, PnL wired to Supabase, and buttons that actually do something. This sets the table for the trading scheduler.

We wire a minimal orchestrator with a primed LP-copy scanner and a policy-driven monitor that runs in dry-run, notifies via Telegram, reads positions from Supabase, and calls execution logic via imports (no gRPC).

We build a robust scanner that reads a leader’s recent transactions and extracts DLMM position inits as (poolAddress, positionPda) intents — no brittle bin-array decoding, just clean signals my scheduler can act on.

Kicking off a new series: revive the old defi_server stack I built at Taigo, drop a new bot/ module on top, and ship a scheduler that can copy-trade Meteora LPs — with PnL tracked and later expanded to memecoins, xStocks, and perps.

Final wrap-up for the Solana Integration milestone: 5-min demo, slides, deliverables checklist, tests, and canister URLs.

We finish the vault branch for SOL and SPL: deposits, cancels, locks, unlocks, and completion — entirely in-canister state. Plus, the full Solana suite now passes.

We include the Solana token registry tests (incl. Token-2022), fix flaky JSON-RPC shapes, and make the test harness robust with `include_bytes!` + workspace-aware wasm paths.

We continue the Solana testing story by building a clean HTTP-outcall mocking layer, composable responders, and readable integration tests.

We refractored and improved our testing architecture and expanded it to include a fully-fledged solana backend canister integration test flow.

Let's create some spl tokens so we can generate a fully fledged test with orders containing solana tokens.

Everything is ready for us to create orders in the frontend containing solana and executing the full offramping flow.

Third Chain Fusion grant log: adding solana wallet adapter in the frontend.

Third Chain Fusion grant log: wiring icRamp's core backend with the Solana canister, persisting canister IDs, and preparing escrow flows for SOL/SPL assets.

Third Chain Fusion grant log: wiring icRamp's core backend with the Solana canister, persisting canister IDs, and preparing escrow flows for SOL/SPL assets.

Second Chain Fusion grant: building a Solana canister with safe token registry and a thin vault to coordinate escrow.

Bringing Bitcoin and Solana native actions to ICP: setup, pitfalls, and tests.